Re: [ANNOUNCEMENT] (tentative) Android generic V4L2 camera HAL

2012-06-25 Thread Aguirre, Sergio
(+ My gmail address, please start using that address from next week
on, since I'm leaving TI)

Hi Guennadi,

Thanks a lot for sharing these! Nice job.

I immediately noticed you have changes on hardware/ti/omap4xxx/
subproject. So, Which devices did you used for testing this?

I got confused since you had changes for the Samsung Nexus S, which
has an Exynos chip...

And you also have this Renesas Mackerel, which seems to use a SuperH 7372.

Or maybe you just patched the omap4xxx related file to fix a build :)

Regards,
Sergio

On Mon, Jun 25, 2012 at 8:55 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
 Hi all

 It's been a while since I've actually done this work. We have been waiting
 for various formalities to be resolved to be able to publish this work
 upstream. There are still a couple of formal issues to sort out before we
 can begin the submission process, but at least it has been decided to
 release patches for independent review and testing.

 For now I've uploaded a development snapshot to

 http://download.open-technology.de/android/20120625/

 In the future we probably will provide git trees at least for the
 system/media/v4l_camera development.

 Enjoy:-) Any comments welcome.

 Thanks
 Guennadi
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/
--
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: [PATCH] V4L: soc-camera: (cosmetic) use a more explicit name for a host handler

2012-05-08 Thread Aguirre, Sergio
Hi Guennadi,

On Tue, May 8, 2012 at 12:00 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
 Use enum_framesizes instead of enum_fsizes to more precisely follow
 the name of the respective ioctl().

 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de

Looks good to me!

I'll redo my patch following this ioctl name matching.

Reviewed-by: Sergio Aguirre sergio.a.agui...@gmail.com

Regards,
Sergio

 ---
  drivers/media/video/soc_camera.c |   14 +++---
  include/media/soc_camera.h       |    2 +-
  2 files changed, 8 insertions(+), 8 deletions(-)

 diff --git a/drivers/media/video/soc_camera.c 
 b/drivers/media/video/soc_camera.c
 index eb25756..b980f99 100644
 --- a/drivers/media/video/soc_camera.c
 +++ b/drivers/media/video/soc_camera.c
 @@ -257,13 +257,13 @@ static int soc_camera_g_std(struct file *file, void 
 *priv, v4l2_std_id *a)
        return v4l2_subdev_call(sd, core, g_std, a);
  }

 -static int soc_camera_enum_fsizes(struct file *file, void *fh,
 +static int soc_camera_enum_framesizes(struct file *file, void *fh,
                                         struct v4l2_frmsizeenum *fsize)
  {
        struct soc_camera_device *icd = file-private_data;
        struct soc_camera_host *ici = to_soc_camera_host(icd-parent);

 -       return ici-ops-enum_fsizes(icd, fsize);
 +       return ici-ops-enum_framesizes(icd, fsize);
  }

  static int soc_camera_reqbufs(struct file *file, void *priv,
 @@ -1241,8 +1241,8 @@ static int default_s_parm(struct soc_camera_device *icd,
        return v4l2_subdev_call(sd, video, s_parm, parm);
  }

 -static int default_enum_fsizes(struct soc_camera_device *icd,
 -                         struct v4l2_frmsizeenum *fsize)
 +static int default_enum_framesizes(struct soc_camera_device *icd,
 +                                  struct v4l2_frmsizeenum *fsize)
  {
        int ret;
        struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
 @@ -1295,8 +1295,8 @@ int soc_camera_host_register(struct soc_camera_host 
 *ici)
                ici-ops-set_parm = default_s_parm;
        if (!ici-ops-get_parm)
                ici-ops-get_parm = default_g_parm;
 -       if (!ici-ops-enum_fsizes)
 -               ici-ops-enum_fsizes = default_enum_fsizes;
 +       if (!ici-ops-enum_framesizes)
 +               ici-ops-enum_framesizes = default_enum_framesizes;

        mutex_lock(list_lock);
        list_for_each_entry(ix, hosts, list) {
 @@ -1386,7 +1386,7 @@ static const struct v4l2_ioctl_ops soc_camera_ioctl_ops 
 = {
        .vidioc_s_input          = soc_camera_s_input,
        .vidioc_s_std            = soc_camera_s_std,
        .vidioc_g_std            = soc_camera_g_std,
 -       .vidioc_enum_framesizes  = soc_camera_enum_fsizes,
 +       .vidioc_enum_framesizes  = soc_camera_enum_framesizes,
        .vidioc_reqbufs          = soc_camera_reqbufs,
        .vidioc_querybuf         = soc_camera_querybuf,
        .vidioc_qbuf             = soc_camera_qbuf,
 diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
 index b5c2b6c..00039d8 100644
 --- a/include/media/soc_camera.h
 +++ b/include/media/soc_camera.h
 @@ -97,7 +97,7 @@ struct soc_camera_host_ops {
        int (*set_bus_param)(struct soc_camera_device *);
        int (*get_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
        int (*set_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
 -       int (*enum_fsizes)(struct soc_camera_device *, struct 
 v4l2_frmsizeenum *);
 +       int (*enum_framesizes)(struct soc_camera_device *, struct 
 v4l2_frmsizeenum *);
        unsigned int (*poll)(struct file *, poll_table *);
  };

 --
 1.7.2.5

--
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: [PATCH v3 05/10] v4l: Add support for ov5640 sensor

2012-05-07 Thread Aguirre, Sergio
Hi Jean-Philippe,

On Mon, May 7, 2012 at 2:27 AM, jean-philippe francois
jp.franc...@cynove.com wrote:
 2012/5/2 Sergio Aguirre saagui...@ti.com:
 This adds a very limited driver for ov5640, which
 only supports:
  - 2592x1944 @ ~7.5 fps
  - 1920x1080 @ ~15 fps,
  - 1280x720 @ ~24 fps,
  - 640x480 @ ~24 fps,
  - 320x240 @ ~24 fps,

 All in YUV422i format, using 1 CSI2 datalane @ 333 MHz.


 There is already a limited driver in mainline for ov5642.
 How does the 5642 differ from 5640 ?

Well, it has several differences, see:

- OV5640 product brief:
http://www.ovt.com/download_document.php?type=sensorsensorid=93
- OV5642 product brief:
http://www.ovt.com/download_document.php?type=sensorsensorid=65

Some of the most notable differences are:
- OV5642 has a MIPI input, for using OV ISP with an external sensor.
- OV5640 has JPEG compression, OV5642 apparently not...
- OV5640 supports anti-shake, OV5640 apparently not...

 Can a single driver handle both chip ?

Maybe, yeah..

Now, for the OV5640 differences above, I'm not enabling much nice
features so far,
so it might be worth a try to attempt the ov5642 driver on my OV5640
as-is, to see
if we can expand it to support both.

I'll also see if I can reach people at OmniVision to consult
feasibility of register settings
sharing.

Regards,
Sergio



 Signed-off-by: Sergio Aguirre saagui...@ti.com
 ---
  drivers/media/video/Kconfig  |    6 +
  drivers/media/video/Makefile |    1 +
  drivers/media/video/ov5640.c |  948 
 ++
  include/media/ov5640.h       |   10 +
  4 files changed, 965 insertions(+), 0 deletions(-)
  create mode 100644 drivers/media/video/ov5640.c
  create mode 100644 include/media/ov5640.h

 diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
 index 4482ac4..cc76652 100644
 --- a/drivers/media/video/Kconfig
 +++ b/drivers/media/video/Kconfig
 @@ -480,6 +480,12 @@ config VIDEO_OV7670
          OV7670 VGA camera.  It currently only works with the M88ALP01
          controller.

 +config VIDEO_OV5640
 +       tristate OmniVision OV5640 sensor support
 +       depends on I2C  VIDEO_V4L2
 +       help
 +         This is a ov5640 camera driver
 +
  config VIDEO_VS6624
        tristate ST VS6624 sensor support
        depends on VIDEO_V4L2  I2C
 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
 index c95cc0d..da40ab3 100644
 --- a/drivers/media/video/Makefile
 +++ b/drivers/media/video/Makefile
 @@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_CX25840) += cx25840/
  obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
  obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
  obj-$(CONFIG_VIDEO_OV7670)     += ov7670.o
 +obj-$(CONFIG_VIDEO_OV5640)     += ov5640.o
  obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
  obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
  obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
 diff --git a/drivers/media/video/ov5640.c b/drivers/media/video/ov5640.c
 new file mode 100644
 index 000..2a64d50
 --- /dev/null
 +++ b/drivers/media/video/ov5640.c
 @@ -0,0 +1,948 @@
 +/*
 + * OmniVision OV5640 sensor driver
 + *
 + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License as
 + * published by the Free Software Foundation version 2.
 + *
 + * This program is distributed as is WITHOUT ANY WARRANTY of any
 + * kind, whether express or implied; without even the implied warranty
 + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +
 +#include linux/videodev2.h
 +#include linux/slab.h
 +#include linux/i2c.h
 +#include linux/log2.h
 +#include linux/delay.h
 +#include linux/module.h
 +
 +#include media/v4l2-device.h
 +#include media/v4l2-subdev.h
 +#include media/v4l2-ctrls.h
 +
 +#include media/ov5640.h
 +
 +/* OV5640 has only one fixed colorspace per pixelcode */
 +struct ov5640_datafmt {
 +       enum v4l2_mbus_pixelcode        code;
 +       enum v4l2_colorspace            colorspace;
 +};
 +
 +struct ov5640_timing_cfg {
 +       u16 x_addr_start;
 +       u16 y_addr_start;
 +       u16 x_addr_end;
 +       u16 y_addr_end;
 +       u16 h_output_size;
 +       u16 v_output_size;
 +       u16 h_total_size;
 +       u16 v_total_size;
 +       u16 isp_h_offset;
 +       u16 isp_v_offset;
 +       u8 h_odd_ss_inc;
 +       u8 h_even_ss_inc;
 +       u8 v_odd_ss_inc;
 +       u8 v_even_ss_inc;
 +};
 +
 +enum ov5640_size {
 +       OV5640_SIZE_QVGA,
 +       OV5640_SIZE_VGA,
 +       OV5640_SIZE_720P,
 +       OV5640_SIZE_1080P,
 +       OV5640_SIZE_5MP,
 +       OV5640_SIZE_LAST,
 +};
 +
 +static const struct v4l2_frmsize_discrete ov5640_frmsizes[OV5640_SIZE_LAST] 
 = {
 +       {  320,  240 },
 +       {  640,  480 },
 +       { 1280,  720 },
 +       { 1920, 1080 },
 +       { 2592, 1944 },
 +};
 +
 +/* Find a frame size in an array */
 +static int ov5640_find_framesize(u32 

Re: Android Support for camera?

2012-05-07 Thread Aguirre, Sergio
Hi Sriram,

On Mon, May 7, 2012 at 10:33 AM, Sriram V vshrir...@gmail.com wrote:
 Hi Sergio,
  I understand that you are working on providing Android HAL Support
 for camera on omap4.

That's right. Not an active task at the moment, due to some other
stuff going on,
but yes, I have that task pending to do.

  Were you able to capture and record?

Well, I'm trying to take these patches as a reference:

http://review.omapzoom.org/#/q/project:platform/hardware/ti/omap4xxx+topic:usbcamera,n,z

Which are implementing V4L2 camera support for the CameraHAL,
currently tested with
the UVC camera driver only.

So, I need to set the IOCTLs to program the omap4iss media controller
device, to set a
usecase, and start preview.

I'll keep you posted.

Regards,
Sergio


  --
 Regards,
 Sriram
--
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: Android Support for camera?

2012-05-07 Thread Aguirre, Sergio
Hi Guennadi,

On Mon, May 7, 2012 at 4:25 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
 Hi Sergio

 On Mon, 7 May 2012, Aguirre, Sergio wrote:

 Hi Sriram,

 On Mon, May 7, 2012 at 10:33 AM, Sriram V vshrir...@gmail.com wrote:
  Hi Sergio,
   I understand that you are working on providing Android HAL Support
  for camera on omap4.

 That's right. Not an active task at the moment, due to some other
 stuff going on,
 but yes, I have that task pending to do.

   Were you able to capture and record?

 Well, I'm trying to take these patches as a reference:

 http://review.omapzoom.org/#/q/project:platform/hardware/ti/omap4xxx+topic:usbcamera,n,z

 Which are implementing V4L2 camera support for the CameraHAL,
 currently tested with
 the UVC camera driver only.

 I've implemented a (pretty basic so far) V4L2 camera HAL for android
 (ICS), patche submission is pending legal clarifications... I hope to
 manage to push them into the upstream android, after which they shall
 become available to all platforms. I've implemented the HAL as a
 platform-agnostic library in C with a minimal (and naive;-)) C++ glue. I'm
 sure, those patches will need some improvements, but I'd be happy, if they
 could be taken as a basis.

Ok, good to know.

Please share them whenever you get over those legal clarifications :)

Maybe we can work out a nice and complete solution all together!

Regards,
Sergio

Regards,
Sergio


 Thanks
 Guennadi

 So, I need to set the IOCTLs to program the omap4iss media controller
 device, to set a
 usecase, and start preview.

 I'll keep you posted.

 Regards,
 Sergio

 
   --
  Regards,
  Sriram

 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/
--
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: [PATCH] v4l: soc-camera: Add support for enum_frameintervals ioctl

2012-05-04 Thread Aguirre, Sergio
Hi Guennadi,

No problem.

On Fri, May 4, 2012 at 10:05 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
 Hi Sergio

 Sorry about the delay.

 On Wed, 18 Apr 2012, Aguirre, Sergio wrote:

 From: Sergio Aguirre saagui...@ti.com

 Signed-off-by: Sergio Aguirre saagui...@ti.com
 ---
  drivers/media/video/soc_camera.c |   37 
 +
  include/media/soc_camera.h       |    1 +
  2 files changed, 38 insertions(+), 0 deletions(-)

 diff --git a/drivers/media/video/soc_camera.c 
 b/drivers/media/video/soc_camera.c
 index eb25756..62c8956 100644
 --- a/drivers/media/video/soc_camera.c
 +++ b/drivers/media/video/soc_camera.c
 @@ -266,6 +266,15 @@ static int soc_camera_enum_fsizes(struct file
 *file, void *fh,
       return ici-ops-enum_fsizes(icd, fsize);
  }

 +static int soc_camera_enum_fivals(struct file *file, void *fh,

 fivals is a bit short for my taste. Yes, I know about the
 *_enum_fsizes() precedent in soc_camera.c, we should have used a more
 descriptive name for that too. So, maybe I'll push a patch to change that
 to enum_frmsizes() or enum_framesizes().

Agreed.


 But that brings in a larger question, which is also the reason, why I
 added a couple more people to the CC: the following 3 operations in struct
 v4l2_subdev_video_ops don't make me particularly happy:

        int (*enum_framesizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum 
 *fsize);
        int (*enum_frameintervals)(struct v4l2_subdev *sd, struct 
 v4l2_frmivalenum *fival);
        int (*enum_mbus_fsizes)(struct v4l2_subdev *sd,
                             struct v4l2_frmsizeenum *fsize);

 The problems are:

 1. enum_framesizes and enum_mbus_fsizes seem to be identical (yes, I see
 my Sob under the latter:-()

Yeah, IMHO, the mbus one should go, since there's no mbus specific structure
being handed as a parameter.

 2. both struct v4l2_frmsizeenum and struct v4l2_frmivalenum are the
 structs, used in the respective V4L2 ioctl()s, and they both contain a
 field for a fourcc value, which doesn't make sense to subdevice drivers.
 So far the only driver combination in the mainline, that I see, that uses
 these operations is marvell-ccic  ov7670. These drivers just ignore the
 pixel format. Relatively recently enum_mbus_fsizes() has been added to
 soc-camera, and this patch is adding enum_frameintervals(). Both these
 implementations abuse the .pixel_format field to pass a media-bus code
 value in it to subdevice drivers. This sends meaningful information to
 subdevice drivers, but is really a hack, rather than a proper
 implementation.

True.


 Any idea how to improve this? Shall we create mediabus clones of those
 structs with an mbus code instead of fourcc, and drop one of the above
 enum_framesizes() operations?

Well, to add more confusion to this.. :)

We have this v4l2-subdev IOCTLs exported to userspace:

#define VIDIOC_SUBDEV_ENUM_FRAME_SIZE \
_IOWR('V', 74, struct v4l2_subdev_frame_size_enum)
#define VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL \
_IOWR('V', 75, struct v4l2_subdev_frame_interval_enum)

Which in drivers/media/video/v4l2-subdev.c, are translated to pad ops:
- v4l2_subdev_call(... enum_frame_size ...);
- v4l2_subdev_call(... enum_frame_interval ...);

respectively.

So, this is also another thing that's causing some confusion.

Does soc_camera use pad ops?

Regards,
Sergio


 Thanks
 Guennadi

 +                                struct v4l2_frmivalenum *fival)
 +{
 +     struct soc_camera_device *icd = file-private_data;
 +     struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
 +
 +     return ici-ops-enum_fivals(icd, fival);
 +}
 +
  static int soc_camera_reqbufs(struct file *file, void *priv,
                             struct v4l2_requestbuffers *p)
  {
 @@ -1266,6 +1275,31 @@ static int default_enum_fsizes(struct
 soc_camera_device *icd,
       return 0;
  }

 +static int default_enum_fivals(struct soc_camera_device *icd,
 +                       struct v4l2_frmivalenum *fival)
 +{
 +     int ret;
 +     struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
 +     const struct soc_camera_format_xlate *xlate;
 +     __u32 pixfmt = fival-pixel_format;
 +     struct v4l2_frmivalenum fival_sd = *fival;
 +
 +     xlate = soc_camera_xlate_by_fourcc(icd, pixfmt);
 +     if (!xlate)
 +             return -EINVAL;
 +     /* map xlate-code to pixel_format, sensor only handle xlate-code*/
 +     fival_sd.pixel_format = xlate-code;
 +
 +     ret = v4l2_subdev_call(sd, video, enum_frameintervals, fival_sd);
 +     if (ret  0)
 +             return ret;
 +
 +     *fival = fival_sd;
 +     fival-pixel_format = pixfmt;
 +
 +     return 0;
 +}
 +
  int soc_camera_host_register(struct soc_camera_host *ici)
  {
       struct soc_camera_host *ix;
 @@ -1297,6 +1331,8 @@ int soc_camera_host_register(struct soc_camera_host 
 *ici)
               ici-ops-get_parm = default_g_parm;
       if (!ici-ops-enum_fsizes)
               ici-ops

Re: [PATCH v3 07/10] arm: omap4430sdp: Add support for omap4iss camera

2012-05-03 Thread Aguirre, Sergio
Hi Sakari,

Thanks for reviewing.

On Wed, May 2, 2012 at 2:47 PM, Sakari Ailus sakari.ai...@iki.fi wrote:

 Hi Sergio,

 Thanks for the patches!!

 On Wed, May 02, 2012 at 10:15:46AM -0500, Sergio Aguirre wrote:
 ...
 +static int sdp4430_ov_cam1_power(struct v4l2_subdev *subdev, int on)
 +{
 +     struct device *dev = subdev-v4l2_dev-dev;
 +     int ret;
 +
 +     if (on) {
 +             if (!regulator_is_enabled(sdp4430_cam2pwr_reg)) {
 +                     ret = regulator_enable(sdp4430_cam2pwr_reg);
 +                     if (ret) {
 +                             dev_err(dev,
 +                                     Error in enabling sensor power 
 regulator 'cam2pwr'\n);
 +                             return ret;
 +                     }
 +
 +                     msleep(50);
 +             }
 +
 +             gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 1);
 +             msleep(10);
 +             ret = clk_enable(sdp4430_cam1_aux_clk); /* Enable XCLK */
 +             if (ret) {
 +                     dev_err(dev,
 +                             Error in clk_enable() in %s(%d)\n,
 +                             __func__, on);
 +                     gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
 +                     return ret;
 +             }
 +             msleep(10);
 +     } else {
 +             clk_disable(sdp4430_cam1_aux_clk);
 +             msleep(1);
 +             gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
 +             if (regulator_is_enabled(sdp4430_cam2pwr_reg)) {
 +                     ret = regulator_disable(sdp4430_cam2pwr_reg);
 +                     if (ret) {
 +                             dev_err(dev,
 +                                     Error in disabling sensor power 
 regulator 'cam2pwr'\n);
 +                             return ret;
 +                     }
 +             }
 +     }
 +
 +     return 0;
 +}

 Isn't this something that should be part of the sensor driver? There's
 nothing in the above code that would be board specific, except the names of
 the clocks, regulators and GPIOs. The sensor driver could hold the names
 instead; this would be also compatible with the device tree.

Agreed. I see what you mean...

I'll take care of that.


 It should be possible to have s_power() callback NULL, too.

 +static int sdp4430_ov_cam2_power(struct v4l2_subdev *subdev, int on)
 +{
 +     struct device *dev = subdev-v4l2_dev-dev;
 +     int ret;
 +
 +     if (on) {
 +             u8 gpoctl = 0;
 +
 +             ret = regulator_enable(sdp4430_cam2pwr_reg);
 +             if (ret) {
 +                     dev_err(dev,
 +                             Error in enabling sensor power regulator 
 'cam2pwr'\n);
 +                     return ret;
 +             }
 +
 +             msleep(50);
 +
 +             if (twl_i2c_read_u8(TWL_MODULE_AUDIO_VOICE, gpoctl,
 +                                 TWL6040_REG_GPOCTL))
 +                     return -ENODEV;
 +             if (twl_i2c_write_u8(TWL_MODULE_AUDIO_VOICE,
 +                                  gpoctl | TWL6040_GPO3,
 +                                  TWL6040_REG_GPOCTL))
 +                     return -ENODEV;

 The above piece of code looks quite interesting. What does it do?

Well, this is because the camera adapter board in 4430SDP has 3
sensors actually:

- 1 Sony IMX060 12.1 MP sensor
- 2 OmniVision OV5650 sensors

And there's 3 wideband analog switches, like this:

http://www.analog.com/static/imported-files/data_sheets/ADG936_936R.pdf

That basically select either IMX060 or OV5650 for CSI2A input.

So, this commands are because the TWL6040 chip has a GPO pin to toggle
this, instead
of an OMAP GPIO (Don't ask me why :) )

Anyways... I see your point, maybe this should be explained better
through a comment.

Regards,
Sergio

 Kind 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


Re: [PATCH v3 07/10] arm: omap4430sdp: Add support for omap4iss camera

2012-05-03 Thread Aguirre, Sergio
Hi Sakari,

On Thu, May 3, 2012 at 7:03 AM, Aguirre, Sergio saagui...@ti.com wrote:
 Hi Sakari,

 Thanks for reviewing.

 On Wed, May 2, 2012 at 2:47 PM, Sakari Ailus sakari.ai...@iki.fi wrote:

 Hi Sergio,

 Thanks for the patches!!

 On Wed, May 02, 2012 at 10:15:46AM -0500, Sergio Aguirre wrote:
 ...
 +static int sdp4430_ov_cam1_power(struct v4l2_subdev *subdev, int on)
 +{
 +     struct device *dev = subdev-v4l2_dev-dev;
 +     int ret;
 +
 +     if (on) {
 +             if (!regulator_is_enabled(sdp4430_cam2pwr_reg)) {
 +                     ret = regulator_enable(sdp4430_cam2pwr_reg);
 +                     if (ret) {
 +                             dev_err(dev,
 +                                     Error in enabling sensor power 
 regulator 'cam2pwr'\n);
 +                             return ret;
 +                     }
 +
 +                     msleep(50);
 +             }
 +
 +             gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 1);
 +             msleep(10);
 +             ret = clk_enable(sdp4430_cam1_aux_clk); /* Enable XCLK */
 +             if (ret) {
 +                     dev_err(dev,
 +                             Error in clk_enable() in %s(%d)\n,
 +                             __func__, on);
 +                     gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
 +                     return ret;
 +             }
 +             msleep(10);
 +     } else {
 +             clk_disable(sdp4430_cam1_aux_clk);
 +             msleep(1);
 +             gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
 +             if (regulator_is_enabled(sdp4430_cam2pwr_reg)) {
 +                     ret = regulator_disable(sdp4430_cam2pwr_reg);
 +                     if (ret) {
 +                             dev_err(dev,
 +                                     Error in disabling sensor power 
 regulator 'cam2pwr'\n);
 +                             return ret;
 +                     }
 +             }
 +     }
 +
 +     return 0;
 +}

 Isn't this something that should be part of the sensor driver? There's
 nothing in the above code that would be board specific, except the names of
 the clocks, regulators and GPIOs. The sensor driver could hold the names
 instead; this would be also compatible with the device tree.

 Agreed. I see what you mean...

 I'll take care of that.

Can you please check out these patches?

1. 
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/cb6c10d58053180364461e6bc8d30d1ec87e6e22
2. 
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/6732e0db25c6647b34ef8f01c244a49a1fd6b45d
3. 
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/d61c4e3142dc9cae972f9128fe73d986838c0ca1
4. 
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/e83f36001c7f7cbe184ad094d9b0c95c39e5028f

I want to see if I got your point properly...

Regards,
Sergio



 It should be possible to have s_power() callback NULL, too.

 +static int sdp4430_ov_cam2_power(struct v4l2_subdev *subdev, int on)
 +{
 +     struct device *dev = subdev-v4l2_dev-dev;
 +     int ret;
 +
 +     if (on) {
 +             u8 gpoctl = 0;
 +
 +             ret = regulator_enable(sdp4430_cam2pwr_reg);
 +             if (ret) {
 +                     dev_err(dev,
 +                             Error in enabling sensor power regulator 
 'cam2pwr'\n);
 +                     return ret;
 +             }
 +
 +             msleep(50);
 +
 +             if (twl_i2c_read_u8(TWL_MODULE_AUDIO_VOICE, gpoctl,
 +                                 TWL6040_REG_GPOCTL))
 +                     return -ENODEV;
 +             if (twl_i2c_write_u8(TWL_MODULE_AUDIO_VOICE,
 +                                  gpoctl | TWL6040_GPO3,
 +                                  TWL6040_REG_GPOCTL))
 +                     return -ENODEV;

 The above piece of code looks quite interesting. What does it do?

 Well, this is because the camera adapter board in 4430SDP has 3
 sensors actually:

 - 1 Sony IMX060 12.1 MP sensor
 - 2 OmniVision OV5650 sensors

 And there's 3 wideband analog switches, like this:

 http://www.analog.com/static/imported-files/data_sheets/ADG936_936R.pdf

 That basically select either IMX060 or OV5650 for CSI2A input.

 So, this commands are because the TWL6040 chip has a GPO pin to toggle
 this, instead
 of an OMAP GPIO (Don't ask me why :) )

 Anyways... I see your point, maybe this should be explained better
 through a comment.

 Regards,
 Sergio

 Kind 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


Re: [PATCH v3 00/10] v4l2: OMAP4 ISS driver + Sensor + Board support

2012-05-02 Thread Aguirre, Sergio
On Wed, May 2, 2012 at 10:15 AM, Sergio Aguirre saagui...@ti.com wrote:
 Hi everyone,

 It's been a long time since last version (5 months)! :)

 This is the third version of the OMAP4 ISS driver,
 which uses Media Controller and videobuf2 frameworks.

 This patchset should apply cleanly on top of v3.4-rc5 kernel tag.

 This driver attempts to provide an fully open source solution to
 control the OMAP4 Imaging SubSystem (a.k.a. ISS).

 Starts with just CSI2-A/B interface support, and pretends to be
 ready for expansion to add support to the many ISS block modules
 as possible.

 Please see newly added documentation for more details:

 Documentation/video4linux/omap4_camera.txt

 Any comments/complaints are welcome. :)

Apologies, forgot to mention this:

Tested with these patchsets:
- Sakari's patches for N9 and some v4l2 changes:
http://www.spinics.net/lists/linux-media/msg45052.html
- CMA v24: http://www.spinics.net/lists/linux-media/msg46106.html

Both rebased to v3.4-rc5.

Regards,
Sergio


 Changes since v2:
 - Supports CSI2B now!
 - Add support for RAW8.
 - Usage of V4L2_CID_PIXEL_RATE, instead of dphy configuration in boardfile
  (similar to omap3isp)
 - Removes save/restore support for now, as it is broken.
 - Attend several comments form Sakari Ailus (Thanks Sakari!)
 - Populate hw_revision in media_dev struct.
 - Ported several fixes pushed for omap3isp (Thanks Laurent!)
 - Use module_platform_driver.
 - Use proposed generic v4l2_subdev_link_validate.
 - Move OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_CAMERA_RX handle to omap4iss code,
  instead of board file.

 Changes since v1:
 - Simplification of auxclk handlign in board files
 - Use of HWMOD declaration for assisted platform_device creation.
 - Videobuf2 migration (Removal of custom iss_queue buffer handling driver)

 Regards,
 Sergio

 Sergio Aguirre (10):
  mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value
  OMAP4: hwmod: Include CSI2A/B and CSIPHY1/2 memory sections
  OMAP4: Add base addresses for ISS
  v4l: Add support for omap4iss driver
  v4l: Add support for ov5640 sensor
  v4l: Add support for ov5650 sensor
  arm: omap4430sdp: Add support for omap4iss camera
  arm: omap4panda: Add support for omap4iss camera
  omap2plus: Add support for omap4iss camera
  arm: Add support for CMA for omap4iss driver

  Documentation/video4linux/omap4_camera.txt    |   64 ++
  arch/arm/configs/omap2plus_defconfig          |    2 +
  arch/arm/mach-omap2/Kconfig                   |   32 +
  arch/arm/mach-omap2/Makefile                  |    3 +
  arch/arm/mach-omap2/board-4430sdp-camera.c    |  415 
  arch/arm/mach-omap2/board-4430sdp.c           |   20 +
  arch/arm/mach-omap2/board-omap4panda-camera.c |  209 
  arch/arm/mach-omap2/devices.c                 |   40 +
  arch/arm/mach-omap2/devices.h                 |    4 +
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c    |   22 +-
  drivers/media/video/Kconfig                   |   25 +
  drivers/media/video/Makefile                  |    3 +
  drivers/media/video/omap4iss/Makefile         |    6 +
  drivers/media/video/omap4iss/iss.c            | 1159 +
  drivers/media/video/omap4iss/iss.h            |  121 +++
  drivers/media/video/omap4iss/iss_csi2.c       | 1368 
 +
  drivers/media/video/omap4iss/iss_csi2.h       |  155 +++
  drivers/media/video/omap4iss/iss_csiphy.c     |  281 +
  drivers/media/video/omap4iss/iss_csiphy.h     |   51 +
  drivers/media/video/omap4iss/iss_regs.h       |  244 +
  drivers/media/video/omap4iss/iss_video.c      | 1123 
  drivers/media/video/omap4iss/iss_video.h      |  201 
  drivers/media/video/ov5640.c                  |  948 +
  drivers/media/video/ov5650.c                  |  733 +
  include/linux/mfd/twl6040.h                   |    2 +-
  include/media/omap4iss.h                      |   65 ++
  include/media/ov5640.h                        |   10 +
  include/media/ov5650.h                        |   10 +
  28 files changed, 7314 insertions(+), 2 deletions(-)
  create mode 100644 Documentation/video4linux/omap4_camera.txt
  create mode 100644 arch/arm/mach-omap2/board-4430sdp-camera.c
  create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c
  create mode 100644 drivers/media/video/omap4iss/Makefile
  create mode 100644 drivers/media/video/omap4iss/iss.c
  create mode 100644 drivers/media/video/omap4iss/iss.h
  create mode 100644 drivers/media/video/omap4iss/iss_csi2.c
  create mode 100644 drivers/media/video/omap4iss/iss_csi2.h
  create mode 100644 drivers/media/video/omap4iss/iss_csiphy.c
  create mode 100644 drivers/media/video/omap4iss/iss_csiphy.h
  create mode 100644 drivers/media/video/omap4iss/iss_regs.h
  create mode 100644 drivers/media/video/omap4iss/iss_video.c
  create mode 100644 drivers/media/video/omap4iss/iss_video.h
  create mode 100644 drivers/media/video/ov5640.c
  create mode 100644 drivers/media/video/ov5650.c
  create mode 

Re: [Query] About V4L2_CAP_VIDEO_CAPTURE_MPLANE device types

2012-05-01 Thread Aguirre, Sergio
Hi Sylwester,

Thanks for the very informative reply!

On Tue, May 1, 2012 at 3:08 PM, Sylwester Nawrocki snj...@gmail.com wrote:
 Hi Sergio,

 On 05/01/2012 09:08 PM, Aguirre, Sergio wrote:
 Hi all,

 I wonder if there's an example app for v4l2 devices with
 V4L2_CAP_VIDEO_CAPTURE_MPLANE capability?
 (like capture.c in V4L2 API docs)

 There isn't at the V4L2 API docs, it probably makes sense to add one though.
 I'll try to find a time to prepare a patch for that. A very simple application
 with V4L2_CAP_VIDEO_CAPTURE_MPLANE support can be found here:
 http://thread.gmane.org/gmane.comp.video.dri.devel/65997

 It might be not that straightforward since there is the DMABUF memory type
 used. Some more applications using multi-plane API are available at:
 http://git.infradead.org/users/kmpark/public-apps

 An MMAP memory example can be found here:
 http://git.infradead.org/users/kmpark/public-apps/blob/9c057b001e8873861a70f7025214003837a0860b:/v4l2-mfc-example/mfc.c

 Please see mfc_dec_setup_capture function.

Thanks. I'll check these links in detail.


 Also, does it have to be mutually exclusive with a
 V4L2_CAP_VIDEO_CAPTURE device?

 No, the driver could support both. But it generally makes sense to implement
 only _mplane ioctls at drivers. The multi/single-plane conversion should be
 done in user space. There were some patches for libv4l to support that
 (http://www.spinics.net/lists/linux-media/msg35080.html), but such conversions
 are not yet supported in the v4l libraries yet AFAIK.

Ok. Got it.


 I'm also not sure how is V4L2_CAP_VIDEO_CAPTURE_MPLANE handled in standard
 GStreamer plugins like v4l2src at the moment, having only multi-plane
 interface at the driver might cause additional problems there.

Ok. I guess that's why i was concerned on keeping the non-mplane
support coexisting with this.

Thanks again for your time!

Regards,
Sergio


 --

 Regards,
 Sylwester
--
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: [media-ctl PATCH] Compare entity name length aswell

2012-04-29 Thread Aguirre, Sergio
Hi Laurent,

On Sun, Apr 29, 2012 at 12:40 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Sergio,

 On Saturday 28 April 2012 10:04:01 Aguirre, Sergio wrote:
 On Wed, Apr 25, 2012 at 8:57 AM, Sergio Aguirre saagui...@ti.com wrote:
  Otherwise, some false positives might arise when
  having 2 subdevices with similar names, like:
 
  OMAP4 ISS ISP IPIPEIF
  OMAP4 ISS ISP IPIPE
 
  Before this patch, trying to find OMAP4 ISS ISP IPIPE, resulted
  in a false entity match, retrieving OMAP4 ISS ISP IPIPEIF
  information instead.
 
  Checking length should ensure such cases are handled well.

 Any feedback about this?

 Thanks for the patch, and sorry for the delay.

No problem. :)


  Signed-off-by: Sergio Aguirre saagui...@ti.com
  ---
   src/mediactl.c |    3 ++-
   1 files changed, 2 insertions(+), 1 deletions(-)
 
  diff --git a/src/mediactl.c b/src/mediactl.c
  index 5b8c587..451a386 100644
  --- a/src/mediactl.c
  +++ b/src/mediactl.c
  @@ -66,7 +66,8 @@ struct media_entity *media_get_entity_by_name(struct
  media_device *media, for (i = 0; i  media-entities_count; ++i) {
                 struct media_entity *entity = media-entities[i];
 
  -               if (strncmp(entity-info.name, name, length) == 0)
  +               if ((strncmp(entity-info.name, name, length) == 0) 
  +                   (strlen(entity-info.name) == length))
                         return entity;
         }

 Instead of calling strlen() which has a O(n) complexity, what about just
 checking that the entity name has a '\0' in the length'th position ? Something
 like the following patch:

 From 46bec667b675573cf1ce698c68112e3dbd31930e Mon Sep 17 00:00:00 2001
 From: Sergio Aguirre saagui...@ti.com
 Date: Wed, 25 Apr 2012 08:57:13 -0500
 Subject: [PATCH] Compare name length to avoid false positives in
 media_get_entity_by_name

 If two subdevice have names that only differ by a suffix (such as OMAP4
 ISS ISP IPIPE and OMAP4 ISS ISP IPIPEIF) the media_get_entity_by_name
 function might return a pointer to the entity with the longest name when
 called with the shortest name. Fix this by verifying that the candidate
 entity name length is equal to the requested name length.

 Signed-off-by: Sergio Aguirre saagui...@ti.com
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  src/mediactl.c |    9 -
  src/tools.h    |    1 +
  2 files changed, 9 insertions(+), 1 deletions(-)

 diff --git a/src/mediactl.c b/src/mediactl.c
 index 5b8c587..bc6a713 100644
 --- a/src/mediactl.c
 +++ b/src/mediactl.c
 @@ -63,10 +63,17 @@ struct media_entity *media_get_entity_by_name(struct
 media_device *media,
  {
        unsigned int i;

 +       /* A match is impossible if the entity name is longer than the maximum
 +        * size we can get from the kernel.
 +        */
 +       if (length = FIELD_SIZEOF(struct media_entity_desc, name))
 +               return NULL;
 +

Good idea.

        for (i = 0; i  media-entities_count; ++i) {
                struct media_entity *entity = media-entities[i];

 -               if (strncmp(entity-info.name, name, length) == 0)
 +               if (strncmp(entity-info.name, name, length) == 0 
 +                   entity-info.name[length] == '\0')

ACK.

Your patch is definitely better.

IMHO, I think it'll be more fair if you put yourself as the author of this
new patch, and me as: Reported-by:.

Regards,
Sergio

                        return entity;
        }

 diff --git a/src/tools.h b/src/tools.h
 index e56edb2..de06cb3 100644
 --- a/src/tools.h
 +++ b/src/tools.h
 @@ -23,6 +23,7 @@
  #define __TOOLS_H__

  #define ARRAY_SIZE(array)      (sizeof(array) / sizeof((array)[0]))
 +#define FIELD_SIZEOF(t, f)     (sizeof(((t*)0)-f))

  #endif /* __TOOLS_H__ */

 --
 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: [media-ctl PATCH] Compare entity name length aswell

2012-04-29 Thread Aguirre, Sergio
Hi Laurent,

On Sun, Apr 29, 2012 at 6:13 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Sergio,

 On Sunday 29 April 2012 17:36:43 Aguirre, Sergio wrote:
 On Sun, Apr 29, 2012 at 12:40 PM, Laurent Pinchart wrote:
  On Saturday 28 April 2012 10:04:01 Aguirre, Sergio wrote:
  On Wed, Apr 25, 2012 at 8:57 AM, Sergio Aguirre saagui...@ti.com wrote:
   Otherwise, some false positives might arise when
   having 2 subdevices with similar names, like:
  
   OMAP4 ISS ISP IPIPEIF
   OMAP4 ISS ISP IPIPE
  
   Before this patch, trying to find OMAP4 ISS ISP IPIPE, resulted
   in a false entity match, retrieving OMAP4 ISS ISP IPIPEIF
   information instead.
  
   Checking length should ensure such cases are handled well.
 
  Any feedback about this?
 
  Thanks for the patch, and sorry for the delay.

 No problem. :)

   Signed-off-by: Sergio Aguirre saagui...@ti.com
   ---
    src/mediactl.c |    3 ++-
    1 files changed, 2 insertions(+), 1 deletions(-)
  
   diff --git a/src/mediactl.c b/src/mediactl.c
   index 5b8c587..451a386 100644
   --- a/src/mediactl.c
   +++ b/src/mediactl.c
   @@ -66,7 +66,8 @@ struct media_entity *media_get_entity_by_name(struct
   media_device *media, for (i = 0; i  media-entities_count; ++i) {
                  struct media_entity *entity = media-entities[i];
  
   -               if (strncmp(entity-info.name, name, length) == 0)
   +               if ((strncmp(entity-info.name, name, length) == 0) 
   +                   (strlen(entity-info.name) == length))
                          return entity;
          }
 
  Instead of calling strlen() which has a O(n) complexity, what about just
  checking that the entity name has a '\0' in the length'th position ?
  Something like the following patch:
 
  From 46bec667b675573cf1ce698c68112e3dbd31930e Mon Sep 17 00:00:00 2001
  From: Sergio Aguirre saagui...@ti.com
  Date: Wed, 25 Apr 2012 08:57:13 -0500
  Subject: [PATCH] Compare name length to avoid false positives in
  media_get_entity_by_name
 
  If two subdevice have names that only differ by a suffix (such as OMAP4
  ISS ISP IPIPE and OMAP4 ISS ISP IPIPEIF) the media_get_entity_by_name
  function might return a pointer to the entity with the longest name when
  called with the shortest name. Fix this by verifying that the candidate
  entity name length is equal to the requested name length.
 
  Signed-off-by: Sergio Aguirre saagui...@ti.com
  Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
  ---
   src/mediactl.c |    9 -
   src/tools.h    |    1 +
   2 files changed, 9 insertions(+), 1 deletions(-)
 
  diff --git a/src/mediactl.c b/src/mediactl.c
  index 5b8c587..bc6a713 100644
  --- a/src/mediactl.c
  +++ b/src/mediactl.c
  @@ -63,10 +63,17 @@ struct media_entity *media_get_entity_by_name(struct
  media_device *media,
   {
         unsigned int i;
 
  +       /* A match is impossible if the entity name is longer than the
  maximum +        * size we can get from the kernel.
  +        */
  +       if (length = FIELD_SIZEOF(struct media_entity_desc, name))
  +               return NULL;
  +

 Good idea.

         for (i = 0; i  media-entities_count; ++i) {
                 struct media_entity *entity = media-entities[i];
 
  -               if (strncmp(entity-info.name, name, length) == 0)
  +               if (strncmp(entity-info.name, name, length) == 0 
  +                   entity-info.name[length] == '\0')

 ACK.

 Your patch is definitely better.

 IMHO, I think it'll be more fair if you put yourself as the author of this
 new patch, and me as: Reported-by:.

 It's such a small patch, it's fine :-) Thank you for the proposal nonetheless.

 I've pushed the patch to the repository.

Excellent! Thanks for that :)

Regards,
Sergio


                         return entity;
         }
 
  diff --git a/src/tools.h b/src/tools.h
  index e56edb2..de06cb3 100644
  --- a/src/tools.h
  +++ b/src/tools.h
  @@ -23,6 +23,7 @@
   #define __TOOLS_H__
 
   #define ARRAY_SIZE(array)      (sizeof(array) / sizeof((array)[0]))
  +#define FIELD_SIZEOF(t, f)     (sizeof(((t*)0)-f))
 
   #endif /* __TOOLS_H__ */
 

 --
 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: [media-ctl PATCH] Compare entity name length aswell

2012-04-28 Thread Aguirre, Sergio
Hi Laurent

On Wed, Apr 25, 2012 at 8:57 AM, Sergio Aguirre saagui...@ti.com wrote:
 Otherwise, some false positives might arise when
 having 2 subdevices with similar names, like:

 OMAP4 ISS ISP IPIPEIF
 OMAP4 ISS ISP IPIPE

 Before this patch, trying to find OMAP4 ISS ISP IPIPE, resulted
 in a false entity match, retrieving OMAP4 ISS ISP IPIPEIF
 information instead.

 Checking length should ensure such cases are handled well.

Any feedback about this?

Regards,
Sergio


 Signed-off-by: Sergio Aguirre saagui...@ti.com
 ---
  src/mediactl.c |    3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)

 diff --git a/src/mediactl.c b/src/mediactl.c
 index 5b8c587..451a386 100644
 --- a/src/mediactl.c
 +++ b/src/mediactl.c
 @@ -66,7 +66,8 @@ struct media_entity *media_get_entity_by_name(struct 
 media_device *media,
        for (i = 0; i  media-entities_count; ++i) {
                struct media_entity *entity = media-entities[i];

 -               if (strncmp(entity-info.name, name, length) == 0)
 +               if ((strncmp(entity-info.name, name, length) == 0) 
 +                   (strlen(entity-info.name) == length))
                        return entity;
        }

 --
 1.7.5.4

--
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: ics port for camera hal?

2012-04-23 Thread Aguirre, Sergio
Hi Ryan

On Sun, Apr 22, 2012 at 6:05 AM, Ryan ryanphilip...@googlemail.com wrote:
 Hi,

 Is there an V4L Port in the camera hal implementations on android ice
 cream sandwich which makes use
 of panda v4l camera drivers.

Me and a couple of colleagues in TI are working on this at the moment,
and we hope to have
something useful very soon.

What we have achieved so far is a PandaBoard bootign ICS with support
for UVC cameras, so that
Camera Application can start preview (just that for the moment, plenty
of things to take care of yet..)

But you can check this out here of you are interested on it:

http://omappedia.org/wiki/Building_L27.IS.2.M1_for_PandaBoard,_with_USB_camera_support

Regards,
Sergio

 Thanks  Regards,
 Ryan
--
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: Mipi csi2 driver for Omap4

2012-04-23 Thread Aguirre, Sergio
Hi Steve, Sakari,

On Fri, Apr 20, 2012 at 3:42 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
 Hi Steve,

 On Fri, Apr 20, 2012 at 12:11:38PM +0200, Steve Lindell wrote:
 Hi! I'm developing a mipi csi2 receiver for test purpose and need some
 help of how to capture the data stream from a camera module. I'm using a
 phytec board with a Omap4430 processor running Linux kernel 3.0.9.
 Connected to the MIPI lanes I have a camera module (soled on a flexfilm)
 The camera follows the Mipi csi2 specs and is controlled via an external
 I2C controller. I have activated the camera and its now transmitting a
 test pattern on the Mipi lines (4 line connection).

 I need to capture the stream and store it as a Raw Bayer snapshot. Is this
 possible use Omap4430 and does Linux have the necessary drivers to capture
 the stream. If this driver exists are there any documentation of how to
 implement the driver?

 Is it possible to get some help of how to get started?

 Sergio Aguirre has posted the patches for the Omap 4 Iss to this list some
 time ago. I believe you'll also be able to find them here:

 URL:https://gitorious.org/omap4-v4l2-camera/pages/Home

Thanks Sakari for the reference.


 I guess you'd be also better off using a newer kernel than that.

 Hope this helps... Cc Sergio.

Steve,

I think it'll be easier for you to consider my code as a reference, and
follow as a reference the pandaboard implementation i've been maintaining.

Take a look specially at the devel branch, and to these files:

# Board file
arch/arm/mach-omap2/board-omap4panda-camera.c

# OV5650 Sensor file (which is RAW10)
drivers/media/video/ov5650.c

Please let me know any questions you might have.

I can help you out on getting what you need.

Regards,
Sergio


 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


[PATCH] v4l: soc-camera: Add support for enum_frameintervals ioctl

2012-04-18 Thread Aguirre, Sergio
From: Sergio Aguirre saagui...@ti.com

Signed-off-by: Sergio Aguirre saagui...@ti.com
---
 drivers/media/video/soc_camera.c |   37 +
 include/media/soc_camera.h   |1 +
 2 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index eb25756..62c8956 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -266,6 +266,15 @@ static int soc_camera_enum_fsizes(struct file
*file, void *fh,
return ici-ops-enum_fsizes(icd, fsize);
 }

+static int soc_camera_enum_fivals(struct file *file, void *fh,
+  struct v4l2_frmivalenum *fival)
+{
+   struct soc_camera_device *icd = file-private_data;
+   struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+
+   return ici-ops-enum_fivals(icd, fival);
+}
+
 static int soc_camera_reqbufs(struct file *file, void *priv,
  struct v4l2_requestbuffers *p)
 {
@@ -1266,6 +1275,31 @@ static int default_enum_fsizes(struct
soc_camera_device *icd,
return 0;
 }

+static int default_enum_fivals(struct soc_camera_device *icd,
+ struct v4l2_frmivalenum *fival)
+{
+   int ret;
+   struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+   const struct soc_camera_format_xlate *xlate;
+   __u32 pixfmt = fival-pixel_format;
+   struct v4l2_frmivalenum fival_sd = *fival;
+
+   xlate = soc_camera_xlate_by_fourcc(icd, pixfmt);
+   if (!xlate)
+   return -EINVAL;
+   /* map xlate-code to pixel_format, sensor only handle xlate-code*/
+   fival_sd.pixel_format = xlate-code;
+
+   ret = v4l2_subdev_call(sd, video, enum_frameintervals, fival_sd);
+   if (ret  0)
+   return ret;
+
+   *fival = fival_sd;
+   fival-pixel_format = pixfmt;
+
+   return 0;
+}
+
 int soc_camera_host_register(struct soc_camera_host *ici)
 {
struct soc_camera_host *ix;
@@ -1297,6 +1331,8 @@ int soc_camera_host_register(struct soc_camera_host *ici)
ici-ops-get_parm = default_g_parm;
if (!ici-ops-enum_fsizes)
ici-ops-enum_fsizes = default_enum_fsizes;
+   if (!ici-ops-enum_fivals)
+   ici-ops-enum_fivals = default_enum_fivals;

mutex_lock(list_lock);
list_for_each_entry(ix, hosts, list) {
@@ -1387,6 +1423,7 @@ static const struct v4l2_ioctl_ops
soc_camera_ioctl_ops = {
.vidioc_s_std= soc_camera_s_std,
.vidioc_g_std= soc_camera_g_std,
.vidioc_enum_framesizes  = soc_camera_enum_fsizes,
+   .vidioc_enum_frameintervals  = soc_camera_enum_fivals,
.vidioc_reqbufs  = soc_camera_reqbufs,
.vidioc_querybuf = soc_camera_querybuf,
.vidioc_qbuf = soc_camera_qbuf,
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index b5c2b6c..0a3ac07 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -98,6 +98,7 @@ struct soc_camera_host_ops {
int (*get_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
int (*set_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
int (*enum_fsizes)(struct soc_camera_device *, struct v4l2_frmsizeenum 
*);
+   int (*enum_fivals)(struct soc_camera_device *, struct v4l2_frmivalenum 
*);
unsigned int (*poll)(struct file *, poll_table *);
 };

-- 
1.7.5.4
--
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


[Query] About NV12 pixel format support in a subdevice

2012-04-07 Thread Aguirre, Sergio
Hi everyone,

I'll like to request for your advice on adding NV12 support for my omap4iss
camera driver, which is done after the resizer block in the OMAP4 ISS ISP
(Imaging SubSystem Image Signal Processor).

So, the problem with that, is that I don't see a match for V4L2_PIX_FMT_NV12
pixel format in enum v4l2_mbus_pixelcode.

Now, I wonder what's the best way to describe the format... Is this correct?

V4L2_MBUS_FMT_NV12_1X12

Because every pixel is comprised of a 8-bit Y element, and it's UV components
are grouped in pairs with the next horizontal pixel, whcih in combination
are represented in 8 bits... So it's like that UV component per-pixel is 4-bits.
Not exactly, but it's the best representation I could think of to
simplify things.

I mean, the HW itself writes in memory to 2 contiguous buffers, so there's 2
separate DMA writes. I have to program 2 starting addresses, which, in an
internal non-v4l2-subdev implementation, I have been programming like this:

paddr = start of 32-byte aligned physical address to store buffer
x = width
y = height

Ysize = (x * y)
UVsize = (x / 2) * y
Total size = Ysize + UVsize

Ystart = paddr
UVstart = (paddr + Ysize)

But, in the media controller framework, i have a single DMA output pad, that
creates a v4l2 capture device node, and i'll be queueing a single buffer.

Any advice on how to address this properly? Does anyone has/had a similar need?

Regards,
Sergio
--
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: [Query] About NV12 pixel format support in a subdevice

2012-04-07 Thread Aguirre, Sergio
Hi Guennadi,

Thanks for your reply.

On Sat, Apr 7, 2012 at 4:21 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
 Hi Sergio

 On Sat, 7 Apr 2012, Aguirre, Sergio wrote:

 Hi everyone,

 I'll like to request for your advice on adding NV12 support for my omap4iss
 camera driver, which is done after the resizer block in the OMAP4 ISS ISP
 (Imaging SubSystem Image Signal Processor).

 So, the problem with that, is that I don't see a match for V4L2_PIX_FMT_NV12
 pixel format in enum v4l2_mbus_pixelcode.

 Now, I wonder what's the best way to describe the format... Is this correct?

 V4L2_MBUS_FMT_NV12_1X12

 Because every pixel is comprised of a 8-bit Y element, and it's UV components
 are grouped in pairs with the next horizontal pixel, whcih in combination
 are represented in 8 bits... So it's like that UV component per-pixel is 
 4-bits.
 Not exactly, but it's the best representation I could think of to
 simplify things.

 Do I understand it right, that your resizer is sending the data to the DMA
 engine interleaved, not Y and UV planes separately, and it's only the DMA
 engine, that is separating the planes, when writing to buffers? In such a
 case I'd use a suitable YUV420 V4L2_MBUS_FMT_* format for that and have
 the DMA engine convert it to NV12, similar to what sh_mobile_ceu_camera
 does.

No, it actually has 2 register sets for specifying the start address
for each plane.

So, I have one register that I program with Y-start address, and
another register
that I program with UV-start address.

For both cases, you control the byte offset between every begin of each line.

So, in theory, you could save it interleaved in memory if you want, or
in 2 separate
buffers depending on how you program the address/offset pair.

Regards,
Sergio


 Thanks
 Guennadi

 I mean, the HW itself writes in memory to 2 contiguous buffers, so there's 2
 separate DMA writes. I have to program 2 starting addresses, which, in an
 internal non-v4l2-subdev implementation, I have been programming like this:

 paddr = start of 32-byte aligned physical address to store buffer
 x = width
 y = height

 Ysize = (x * y)
 UVsize = (x / 2) * y
 Total size = Ysize + UVsize

 Ystart = paddr
 UVstart = (paddr + Ysize)

 But, in the media controller framework, i have a single DMA output pad, that
 creates a v4l2 capture device node, and i'll be queueing a single buffer.

 Any advice on how to address this properly? Does anyone has/had a similar 
 need?

 Regards,
 Sergio
 --
 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


 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/
--
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: [Query] About NV12 pixel format support in a subdevice

2012-04-07 Thread Aguirre, Sergio
Hi Guennadi,

On Sat, Apr 7, 2012 at 4:51 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
 On Sat, 7 Apr 2012, Aguirre, Sergio wrote:

 Hi Guennadi,

 Thanks for your reply.

 On Sat, Apr 7, 2012 at 4:21 PM, Guennadi Liakhovetski
 g.liakhovet...@gmx.de wrote:
  Hi Sergio
 
  On Sat, 7 Apr 2012, Aguirre, Sergio wrote:
 
  Hi everyone,
 
  I'll like to request for your advice on adding NV12 support for my 
  omap4iss
  camera driver, which is done after the resizer block in the OMAP4 ISS ISP
  (Imaging SubSystem Image Signal Processor).
 
  So, the problem with that, is that I don't see a match for 
  V4L2_PIX_FMT_NV12
  pixel format in enum v4l2_mbus_pixelcode.
 
  Now, I wonder what's the best way to describe the format... Is this 
  correct?
 
  V4L2_MBUS_FMT_NV12_1X12
 
  Because every pixel is comprised of a 8-bit Y element, and it's UV 
  components
  are grouped in pairs with the next horizontal pixel, whcih in combination
  are represented in 8 bits... So it's like that UV component per-pixel is 
  4-bits.
  Not exactly, but it's the best representation I could think of to
  simplify things.
 
  Do I understand it right, that your resizer is sending the data to the DMA
  engine interleaved, not Y and UV planes separately, and it's only the DMA
  engine, that is separating the planes, when writing to buffers? In such a
  case I'd use a suitable YUV420 V4L2_MBUS_FMT_* format for that and have
  the DMA engine convert it to NV12, similar to what sh_mobile_ceu_camera
  does.

 No, it actually has 2 register sets for specifying the start address
 for each plane.

 Sorry, what it? The DMA engine, right? Then it still looks pretty
 similar to the CEU case to me: it also can either write the data
 interleaved into RAM and produce a YUV420 format, or convert to NV12.
 Which one to do is decided by the format, configured on the video device
 node by the driver.

Hmm, ok. I think I know what you mean now, sorry.

So you're saying I should really use, say: V4L2_MBUS_FMT_YUYV8_1_5X8 as
subdevice format, and let the v4l2 device output node either use:

- V4L2_PIX_FMT_NV12
or
- V4L2_PIX_FMT_YUV420

depending on how I want the DMA engine to organize the data.

Did I got your point correctly?

Thanks for your patience.

Regards,
Sergio


 Thanks
 Guennadi

 So, I have one register that I program with Y-start address, and
 another register
 that I program with UV-start address.

 For both cases, you control the byte offset between every begin of each line.

 So, in theory, you could save it interleaved in memory if you want, or
 in 2 separate
 buffers depending on how you program the address/offset pair.

 Regards,
 Sergio

 
  Thanks
  Guennadi
 
  I mean, the HW itself writes in memory to 2 contiguous buffers, so 
  there's 2
  separate DMA writes. I have to program 2 starting addresses, which, in an
  internal non-v4l2-subdev implementation, I have been programming like 
  this:
 
  paddr = start of 32-byte aligned physical address to store buffer
  x = width
  y = height
 
  Ysize = (x * y)
  UVsize = (x / 2) * y
  Total size = Ysize + UVsize
 
  Ystart = paddr
  UVstart = (paddr + Ysize)
 
  But, in the media controller framework, i have a single DMA output pad, 
  that
  creates a v4l2 capture device node, and i'll be queueing a single buffer.
 
  Any advice on how to address this properly? Does anyone has/had a similar 
  need?
 
  Regards,
  Sergio
  --
  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
 
 
  ---
  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/
--
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: [PATCH] Add support for YUV420 formats

2012-04-07 Thread Aguirre, Sergio
Hi Laurent,

Sorry, forgot to mention that this is for your media-ctl app.

Regards,
Sergio

On Sat, Apr 7, 2012 at 10:54 PM,  saagui...@ti.com wrote:
 From: Sergio Aguirre saagui...@ti.com

 Signed-off-by: Sergio Aguirre saagui...@ti.com
 ---
  src/v4l2subdev.c |    2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

 diff --git a/src/v4l2subdev.c b/src/v4l2subdev.c
 index b886b72..e28ed49 100644
 --- a/src/v4l2subdev.c
 +++ b/src/v4l2subdev.c
 @@ -498,8 +498,10 @@ static struct {
        { Y12, V4L2_MBUS_FMT_Y12_1X12 },
        { YUYV, V4L2_MBUS_FMT_YUYV8_1X16 },
        { YUYV2X8, V4L2_MBUS_FMT_YUYV8_2X8 },
 +       { YUYV1_5X8, V4L2_MBUS_FMT_YUYV8_1_5X8 },
        { UYVY, V4L2_MBUS_FMT_UYVY8_1X16 },
        { UYVY2X8, V4L2_MBUS_FMT_UYVY8_2X8 },
 +       { UYVY1_5X8, V4L2_MBUS_FMT_UYVY8_1_5X8 },
        { SBGGR8, V4L2_MBUS_FMT_SBGGR8_1X8 },
        { SGBRG8, V4L2_MBUS_FMT_SGBRG8_1X8 },
        { SGRBG8, V4L2_MBUS_FMT_SGRBG8_1X8 },
 --
 1.7.5.4

--
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: [PATCH v2 06/11] v4l: Add support for omap4iss driver

2012-03-08 Thread Aguirre, Sergio
Hi Sakari,

On Thu, Jan 26, 2012 at 3:05 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
 Hi Sergio,


 Aguirre, Sergio wrote:

 On Wed, Nov 30, 2011 at 06:14:55PM -0600, Sergio Aguirre wrote:

 ...

 +/*
 + * iss_save_ctx - Saves ISS context.
 + * @iss: OMAP4 ISS device
 + *
 + * Routine for saving the context of each module in the ISS.
 + */
 +static void iss_save_ctx(struct iss_device *iss)
 +{
 +     iss_save_context(iss, iss_reg_list);
 +}


 Do you really, really need to save context related data? Couldn't you
 initialise the device the usual way when e.g. returning from suspended
 state?


 I'll actually have to revisit this more carefuly. I haven't really
 tested Runtime PM on this.

 I think I'll remove this for now, until i come up with something better.


 Usually it's best to recreate the configuration the same way the driver did
 it in the first place. Some registers have side effects so that restoring
 them requires extra care.


 +/*
 + * iss_restore_ctx - Restores ISS context.
 + * @iss: OMAP4 ISS device
 + *
 + * Routine for restoring the context of each module in the ISS.
 + */
 +static void iss_restore_ctx(struct iss_device *iss)
 +{
 +     iss_restore_context(iss, iss_reg_list);
 +}
 +


 ...


 +/*
 + * csi2_irq_ctx_set - Enables CSI2 Context IRQs.
 + * @enable: Enable/disable CSI2 Context interrupts
 + */
 +static void csi2_irq_ctx_set(struct iss_csi2_device *csi2, int enable)
 +{
 +     u32 reg = CSI2_CTX_IRQ_FE;
 +     int i;
 +
 +     if (csi2-use_fs_irq)
 +             reg |= CSI2_CTX_IRQ_FS;
 +
 +     for (i = 0; i  8; i++) {


 8 == number of contexts?


 Yes. This loops from 0 to 7.

 Are you implying that I need to add a define to this?


 I think something that tells it is the number of contexts would be nicer.

 ...


 +     writel(readl(csi2-regs1 + CSI2_SYSCONFIG) |
 +             CSI2_SYSCONFIG_SOFT_RESET,
 +             csi2-regs1 + CSI2_SYSCONFIG);
 +
 +     do {
 +             reg = readl(csi2-regs1 + CSI2_SYSSTATUS)
 +                                 CSI2_SYSSTATUS_RESET_DONE;
 +             if (reg == CSI2_SYSSTATUS_RESET_DONE)
 +                     break;
 +             soft_reset_retries++;
 +             if (soft_reset_retries  5)
 +                     udelay(100);


 How about usleep_range() here? Or omit such a long busyloop. Hardware
 typically resets quite fast.


 I guess i'll try to fine-tune this then.


 I think it's fine to replace it with usleep_range() for now. Fine
 optimisations can be left for later if really needed.

 ...


 +static void csi2_print_status(struct iss_csi2_device *csi2)
 +{
 +     struct iss_device *iss = csi2-iss;
 +
 +     if (!csi2-available)
 +             return;
 +
 +     dev_dbg(iss-dev, -CSI2 Register
 dump-\n);
 +
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, SYSCONFIG);
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, SYSSTATUS);
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, IRQENABLE);
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, IRQSTATUS);
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, CTRL);
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, DBG_H);
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, COMPLEXIO_CFG);
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, COMPLEXIO_IRQSTATUS);
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, SHORT_PACKET);
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, COMPLEXIO_IRQENABLE);
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, DBG_P);
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, TIMING);
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_CTRL1(0));
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_CTRL2(0));
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_DAT_OFST(0));
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_PING_ADDR(0));
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_PONG_ADDR(0));
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_IRQENABLE(0));
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_IRQSTATUS(0));
 +     CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_CTRL3(0));
 +
 +     dev_dbg(iss-dev,
 \n);


 _If_ this is user-triggered, you might want to consider using debugfs for
 the same. Just FYI.


 Ok. I'll see what can I do.


 Just FYI. :-) Thinking about this agian, debugfs might not go well with this
 since the prints may be triggered by the driver.

 ...


 +     /* Skip interrupts until we reach the frame skip count. The CSI2
 will be
 +      * automatically disabled, as the frame skip count has been
 programmed
 +      * in the CSI2_CTx_CTRL1::COUNT field, so reenable it.
 +      *
 +      * It would have been nice to rely on the FRAME_NUMBER interrupt
 instead
 +      * but it turned out that the interrupt is only generated when the
 CSI2
 +      * writes to memory (the CSI2_CTx_CTRL1::COUNT field is decreased
 +      * correctly and reaches 0 when data is forwarded to the video
 port only
 +      * but no interrupt arrives). Maybe a CSI2 hardware bug.
 +      */
 +     if (csi2-frame_skip) {
 +             csi2-frame_skip--;
 +             if (csi2

Re: Video Capture Issue

2012-02-27 Thread Aguirre, Sergio
Sriram,

On Sun, Feb 26, 2012 at 8:54 AM, Sriram V vshrir...@gmail.com wrote:
 Hi,
  When I take the dump of the buffer which is pointed by DATA MEM
 PING ADDRESS. It always shows 0x55.
  Even if i write 0x00 to the address. I do notice that it quickly
 changes to 0x55.
  Under what conditions could this happen? What am i missing here.

If you're using yavta for capture, notice that it clears out the
buffers before queuing them in:

static int video_queue_buffer(struct device *dev, int index, enum
buffer_fill_mode fill)
{
struct v4l2_buffer buf;
int ret;

...
...
if (dev-type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
...
} else {
if (fill  BUFFER_FILL_FRAME)
memset(dev-buffers[buf.index].mem, 0x55, 
dev-buffers[index].size);
if (fill  BUFFER_FILL_PADDING)
memset(dev-buffers[buf.index].mem + 
dev-buffers[index].size,
   0x55, dev-buffers[index].padding);
}
...
}

So, just make sure this condition is not met.


  I do notice that the OMAP4 ISS is tested to work with OV5640 (YUV422
 Frames) and OV5650 (Raw Data)
  When you say 422 Frames only. Do you mean 422-8Bit Mode?.

Yes. When saving YUV422 to memory, you can only use this mode AFAIK.


  I havent tried RAW12 which my device gives, Do i have to update only
 the Data Format Selection register
  of the ISS  for RAW12?

Ok, now it makes sense.

So, if your CSI2 source is giving, you need to make sure:

CSI2_CTX_CTRL2_0.FORMAT[9:0] is:

- 0xAC: RAW12 + EXP16
or
- 0x2C: RAW12

The difference is that the EXP16 variant, will save to memory in
expansion to 2 bytes, instead of 12 bits, so it'll be byte aligned.

Can you try attached patch?

Regards,
Sergio


  Please advice.


 On Thu, Feb 23, 2012 at 11:24 PM, Sriram V vshrir...@gmail.com wrote:
 Hi,
  1) An Hexdump of the captured file shows 0x55 at all locations.
      Is there any buffer location i need to check.
  2) I have tried with  devel branch.
  3) Changing the polarities doesnt help either.
  4) The sensor is giving out YUV422 8Bit Mode,
      Will 0x52001074 = 0x0A1E (UYVY Format)  it bypass the ISP
       and dump directly into memory.

 On 2/23/12, Aguirre, Sergio saagui...@ti.com wrote:
 Hi Sriram,

 On Thu, Feb 23, 2012 at 11:25 AM, Sriram V vshrir...@gmail.com wrote:
 Hi,
  1) I am trying to get a HDMI to CSI Bridge chip working with OMAP4 ISS.
      The issue is the captured frames are completely green in color.

 Sounds like the buffer is all zeroes, can you confirm?

  2) The Chip is configured to output VGA Color bar sequence with
 YUV422-8Bit and
       uses datalane 0 only.
  3) The Format on OMAP4 ISS  is UYVY (Register 0x52001074 = 0x0A1E)
  I am trying to directly dump the data into memory without ISP processing.


  Please advice.

 Just to be clear on your environment, which branch/commitID are you based
 on?

 Regards,
 Sergio


 --
 Regards,
 Sriram
 --
 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



 --
 Regards,
 Sriram



 --
 Regards,
 Sriram
diff --git a/drivers/media/video/omap4iss/iss_csi2.c b/drivers/media/video/omap4iss/iss_csi2.c
index 04985a0..0e8a069 100644
--- a/drivers/media/video/omap4iss/iss_csi2.c
+++ b/drivers/media/video/omap4iss/iss_csi2.c
@@ -106,6 +106,10 @@ static const unsigned int csi2_input_fmts[] = {
 	V4L2_MBUS_FMT_SGBRG8_1X8,
 	V4L2_MBUS_FMT_SGRBG8_1X8,
 	V4L2_MBUS_FMT_SRGGB8_1X8,
+	V4L2_MBUS_FMT_SBGGR12_1X12,
+	V4L2_MBUS_FMT_SGBRG12_1X12,
+	V4L2_MBUS_FMT_SGRBG12_1X12,
+	V4L2_MBUS_FMT_SRGGB12_1X12,
 	V4L2_MBUS_FMT_UYVY8_1X16,
 	V4L2_MBUS_FMT_YUYV8_1X16,
 };
@@ -171,6 +175,23 @@ static const u16 __csi2_fmt_map[][2][2] = {
 			0,
 		},
 	},
+	/* RAW12 formats */
+	{
+		/* Output to memory */
+		{
+			/* No DPCM decompression */
+			CSI2_PIX_FMT_RAW12_EXP16,
+			/* DPCM decompression */
+			0,
+		},
+		/* Output to both */
+		{
+			/* No DPCM decompression */
+			CSI2_PIX_FMT_RAW12_VP,
+			/* DPCM decompression */
+			0,
+		},
+	},
 	/* YUV422 formats */
 	{
 		/* Output to memory */
@@ -220,9 +241,15 @@ static u16 csi2_ctx_map_format(struct iss_csi2_device *csi2)
 	case V4L2_MBUS_FMT_SRGGB8_1X8:
 		fmtidx = 2;
 		break;
+	case V4L2_MBUS_FMT_SBGGR12_1X12:
+	case V4L2_MBUS_FMT_SGBRG12_1X12:
+	case V4L2_MBUS_FMT_SGRBG12_1X12:
+	case V4L2_MBUS_FMT_SRGGB12_1X12:
+		fmtidx = 3;
+		break;
 	case V4L2_MBUS_FMT_UYVY8_1X16:
 	case V4L2_MBUS_FMT_YUYV8_1X16:
-		fmtidx = 3;
+		fmtidx = 4;
 		break;
 	default:
 		WARN(1, KERN_ERR CSI2: pixel format %08x unsupported!\n,
diff --git a/drivers/media/video/omap4iss/iss_csi2.h b/drivers/media/video/omap4iss/iss_csi2.h
index aa81971..beed331 100644
--- a/drivers/media/video/omap4iss/iss_csi2.h
+++ b/drivers/media/video/omap4iss/iss_csi2.h
@@ -32,6 +32,8 @@ enum iss_csi2_pix_formats

Re: Video Capture Issue

2012-02-23 Thread Aguirre, Sergio
Hi Sriram,

On Thu, Feb 23, 2012 at 11:25 AM, Sriram V vshrir...@gmail.com wrote:
 Hi,
  1) I am trying to get a HDMI to CSI Bridge chip working with OMAP4 ISS.
      The issue is the captured frames are completely green in color.

Sounds like the buffer is all zeroes, can you confirm?

  2) The Chip is configured to output VGA Color bar sequence with
 YUV422-8Bit and
       uses datalane 0 only.
  3) The Format on OMAP4 ISS  is UYVY (Register 0x52001074 = 0x0A1E)
  I am trying to directly dump the data into memory without ISP processing.


  Please advice.

Just to be clear on your environment, which branch/commitID are you based on?

Regards,
Sergio


 --
 Regards,
 Sriram
 --
 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
--
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: omap4 v4l media-ctl usage

2012-02-19 Thread Aguirre, Sergio
H Ryan,

On Sun, Feb 19, 2012 at 10:04 AM, Ryan ryanphilip...@googlemail.com wrote:
 Hi Laurent,

 It actually blocks at VIDIOC_DQBUF ioctl and not in STREAMON ioctl.
 Looks like the data is not available.

 Any way of verifying if OMAP is receiving data. Wonder why i keep
 interrupts though?

Can you try again after cherry-picking these 3 commits?:

7ea3af1 ov5640: Move initial config to registering callback
dbe85fd ov5640: Fix s_fmt behaviour
522e30a panda: camera: Fix ddr_freq for OV5640 selection

I'll suggest you to try keeping on latest devel branch head, since
there's many fixes and cleanups I have been pushing in the tree.

Regards,
Sergio

 Is my media-ctl setting up things correctly?

 Thank you.

 Regards,
 Ryan


 On Sun, Feb 19, 2012 at 7:47 PM, Ryan ryanphilip...@googlemail.com wrote:
 Hi Laurent,

 On Sun, Feb 19, 2012 at 2:27 PM, Laurent Pinchart
 laurent.pinch...@ideasonboard.com wrote:
 Hi Ryan,

 On Saturday 18 February 2012 20:59:57 Ryan wrote:
 hello,
 I am using media-ctl on the panda board. The sensor gets detected. But
 media-ctl doesnt print anything.
 The kernel is cloned from omap4 v4l git tree: commit id:
 3bc023462a68f78bb0273848f5ab08a01b434ffa

 what could be wrong in here?

 ~ # ./media-ctl -p
 Opening media device /dev/media0
 Enumerating entities
 Found 0 entities
 Enumerating pads and links
 Device topology

 What steps i need to follow get output from sensor in terms of
 arguments to media-ctl and yavta.

 Could you please first make sure that media-ctl has be compiled against 
 header
 files from the kernel running on your board ?


 Thank you, That did the trick, Now i am able to run media-ctl. I am
 trying to capture YUV422.
 When i run yavta, It blocks infinitely at STREAM ON, I see that the
 ISS interrupts keeps incrementing.
 Am i missing something?

 #yavta /dev/video0  -n1 -c5 -s640x480 -fUYVY -Ftest.yuv
 Device /dev/video0 opened: OMAP4 ISS CSI2a output (media).
 Video format set: width: 640 height: 480 buffer size: 614400
 Video format: UYVY (59565955) 640x480
 1 buffers requested.
 length: 614400 offset: 0
 Buffer 0 mapped at address 0x4028e000.
 [  577.605590] Enable STREAM ON..


 After configuring using the media-ctl, This is how my device topology
 looks like:
 Is this okay?

 Device topology
 - entity 1: OMAP4 ISS CSI2a (2 pads, 2 links)
            type V4L2 subdev subtype Unknown
            device node name /dev/v4l-subdev0
        pad0: Sink [UYVY 640x480]
                - ov5640 3-0036:0 [ENABLED,IMMUTABLE]
        pad1: Source [UYVY 640x480]
                - OMAP4 ISS CSI2a output:0 [ENABLED]

 - entity 2: OMAP4 ISS CSI2a output (1 pad, 1 link)
            type Node subtype V4L
            device node name /dev/video0
        pad0: Sink
                - OMAP4 ISS CSI2a:1 [ENABLED]

 - entity 3: ov5640 3-0036 (1 pad, 1 link)
            type V4L2 subdev subtype Unknown
            device node name /dev/v4l-subdev1
        pad0: Source [UYVY 640x480]
                - OMAP4 ISS CSI2a:0 [ENABLED,IMMUTABLE]



 Thank you,

 Regards,
 Ryan


 --
 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
--
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: [PATCH v2 27/31] omap3isp: Configure CSI-2 phy based on platform data

2012-02-11 Thread Aguirre, Sergio
Hi Sakari,

On Fri, Feb 10, 2012 at 2:32 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
 Hi Sergio,

 Thanks for the review!

 Aguirre, Sergio wrote:
 On Thu, Feb 2, 2012 at 5:54 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
 Configure CSI-2 phy based on platform data in the ISP driver. For that, the
 new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same
 was configured from the board code.

 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 ---
  drivers/media/video/omap3isp/ispcsi2.c   |   10 +++-
  drivers/media/video/omap3isp/ispcsiphy.c |   78 
 ++
  drivers/media/video/omap3isp/ispcsiphy.h |    2 +
  3 files changed, 78 insertions(+), 12 deletions(-)

 diff --git a/drivers/media/video/omap3isp/ispcsi2.c 
 b/drivers/media/video/omap3isp/ispcsi2.c
 index 9313f7c..e2e3d63 100644
 --- a/drivers/media/video/omap3isp/ispcsi2.c
 +++ b/drivers/media/video/omap3isp/ispcsi2.c
 @@ -1068,7 +1068,13 @@ static int csi2_set_stream(struct v4l2_subdev *sd, 
 int enable)
        struct isp_video *video_out = csi2-video_out;

        switch (enable) {
 -       case ISP_PIPELINE_STREAM_CONTINUOUS:
 +       case ISP_PIPELINE_STREAM_CONTINUOUS: {
 +               int ret;
 +
 +               ret = omap3isp_csiphy_config(isp, sd);
 +               if (ret  0)
 +                       return ret;
 +
                if (omap3isp_csiphy_acquire(csi2-phy)  0)
                        return -ENODEV;
                csi2-use_fs_irq = pipe-do_propagation;
 @@ -1092,7 +1098,7 @@ static int csi2_set_stream(struct v4l2_subdev *sd, 
 int enable)
                csi2_if_enable(isp, csi2, 1);
                isp_video_dmaqueue_flags_clr(video_out);
                break;
 -
 +       }
        case ISP_PIPELINE_STREAM_STOPPED:
                if (csi2-state == ISP_PIPELINE_STREAM_STOPPED)
                        return 0;
 diff --git a/drivers/media/video/omap3isp/ispcsiphy.c 
 b/drivers/media/video/omap3isp/ispcsiphy.c
 index 5be37ce..5d7a6ab 100644
 --- a/drivers/media/video/omap3isp/ispcsiphy.c
 +++ b/drivers/media/video/omap3isp/ispcsiphy.c
 @@ -28,6 +28,8 @@
  #include linux/device.h
  #include linux/regulator/consumer.h

 +#include ../../../../arch/arm/mach-omap2/control.h
 +
  #include isp.h
  #include ispreg.h
  #include ispcsiphy.h
 @@ -138,15 +140,73 @@ static void csiphy_dphy_config(struct isp_csiphy *phy)
        isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG1);
  }

 -static int csiphy_config(struct isp_csiphy *phy,
 -                        struct isp_csiphy_dphy_cfg *dphy,
 -                        struct isp_csiphy_lanes_cfg *lanes)
 +/*
 + * TCLK values are OK at their reset values
 + */
 +#define TCLK_TERM      0
 +#define TCLK_MISS      1
 +#define TCLK_SETTLE    14
 +
 +int omap3isp_csiphy_config(struct isp_device *isp,
 +                          struct v4l2_subdev *csi2_subdev)
  {
 +       struct isp_csi2_device *csi2 = v4l2_get_subdevdata(csi2_subdev);
 +       struct isp_pipeline *pipe = to_isp_pipeline(csi2_subdev-entity);
 +       struct isp_v4l2_subdevs_group *subdevs = pipe-external-host_priv;
 +       struct isp_csiphy_dphy_cfg csi2phy;
 +       int csi2_ddrclk_khz;
 +       struct isp_csiphy_lanes_cfg *lanes;
        unsigned int used_lanes = 0;
        unsigned int i;

 +       if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1
 +           || subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
 +               lanes = subdevs-bus.ccp2.lanecfg;
 +       else
 +               lanes = subdevs-bus.csi2.lanecfg;
 +
 +       /* FIXME: Do 34xx / 35xx require something here? */
 +       if (cpu_is_omap3630()) {
 +               u32 cam_phy_ctrl = omap_readl(
 +                       OMAP343X_CTRL_BASE + 
 OMAP3630_CONTROL_CAMERA_PHY_CTRL);

 How about:
               u32 cam_phy_ctrl = 
 omap_ctrl_readl(OMAP3630_CONTROL_CAMERA_PHY_CTRL);
 ?

 Fine for me.

 +
 +               /*
 +                * SCM.CONTROL_CAMERA_PHY_CTRL
 +                * - bit[4]    : CSIPHY1 data sent to CSIB
 +                * - bit [3:2] : CSIPHY1 config: 00 d-phy, 01/10 ccp2
 +                * - bit [1:0] : CSIPHY2 config: 00 d-phy, 01/10 ccp2
 +                */
 +               if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1)
 +                       cam_phy_ctrl |= 1  2;
 +               else if (subdevs-interface == ISP_INTERFACE_CSI2C_PHY1)
 +                       cam_phy_ctrl = 1  2;

 Shouldn't this be:
                        cam_phy_ctrl = ~(1  2);
 ?

 Probably yes. This has come directly as it was in the original board
 code and might not be entirely correct. It works on the N9 at least.

 +
 +               if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
 +                       cam_phy_ctrl |= 1;
 +               else if (subdevs-interface == ISP_INTERFACE_CSI2A_PHY2)
 +                       cam_phy_ctrl = 1;

 ... and:
                        cam_phy_ctrl = ~1;

 +
 +               omap_writel(cam_phy_ctrl,
 +                           OMAP343X_CTRL_BASE

Re: [PATCH v2 27/31] omap3isp: Configure CSI-2 phy based on platform data

2012-02-11 Thread Aguirre, Sergio
On Sat, Feb 11, 2012 at 11:17 AM, Aguirre, Sergio saagui...@ti.com wrote:
 Hi Sakari,

 On Fri, Feb 10, 2012 at 2:32 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
 Hi Sergio,

 Thanks for the review!

 Aguirre, Sergio wrote:
 On Thu, Feb 2, 2012 at 5:54 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
 Configure CSI-2 phy based on platform data in the ISP driver. For that, the
 new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same
 was configured from the board code.

 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 ---
  drivers/media/video/omap3isp/ispcsi2.c   |   10 +++-
  drivers/media/video/omap3isp/ispcsiphy.c |   78 
 ++
  drivers/media/video/omap3isp/ispcsiphy.h |    2 +
  3 files changed, 78 insertions(+), 12 deletions(-)

 diff --git a/drivers/media/video/omap3isp/ispcsi2.c 
 b/drivers/media/video/omap3isp/ispcsi2.c
 index 9313f7c..e2e3d63 100644
 --- a/drivers/media/video/omap3isp/ispcsi2.c
 +++ b/drivers/media/video/omap3isp/ispcsi2.c
 @@ -1068,7 +1068,13 @@ static int csi2_set_stream(struct v4l2_subdev *sd, 
 int enable)
        struct isp_video *video_out = csi2-video_out;

        switch (enable) {
 -       case ISP_PIPELINE_STREAM_CONTINUOUS:
 +       case ISP_PIPELINE_STREAM_CONTINUOUS: {
 +               int ret;
 +
 +               ret = omap3isp_csiphy_config(isp, sd);
 +               if (ret  0)
 +                       return ret;
 +
                if (omap3isp_csiphy_acquire(csi2-phy)  0)
                        return -ENODEV;
                csi2-use_fs_irq = pipe-do_propagation;
 @@ -1092,7 +1098,7 @@ static int csi2_set_stream(struct v4l2_subdev *sd, 
 int enable)
                csi2_if_enable(isp, csi2, 1);
                isp_video_dmaqueue_flags_clr(video_out);
                break;
 -
 +       }
        case ISP_PIPELINE_STREAM_STOPPED:
                if (csi2-state == ISP_PIPELINE_STREAM_STOPPED)
                        return 0;
 diff --git a/drivers/media/video/omap3isp/ispcsiphy.c 
 b/drivers/media/video/omap3isp/ispcsiphy.c
 index 5be37ce..5d7a6ab 100644
 --- a/drivers/media/video/omap3isp/ispcsiphy.c
 +++ b/drivers/media/video/omap3isp/ispcsiphy.c
 @@ -28,6 +28,8 @@
  #include linux/device.h
  #include linux/regulator/consumer.h

 +#include ../../../../arch/arm/mach-omap2/control.h
 +
  #include isp.h
  #include ispreg.h
  #include ispcsiphy.h
 @@ -138,15 +140,73 @@ static void csiphy_dphy_config(struct isp_csiphy 
 *phy)
        isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG1);
  }

 -static int csiphy_config(struct isp_csiphy *phy,
 -                        struct isp_csiphy_dphy_cfg *dphy,
 -                        struct isp_csiphy_lanes_cfg *lanes)
 +/*
 + * TCLK values are OK at their reset values
 + */
 +#define TCLK_TERM      0
 +#define TCLK_MISS      1
 +#define TCLK_SETTLE    14
 +
 +int omap3isp_csiphy_config(struct isp_device *isp,
 +                          struct v4l2_subdev *csi2_subdev)
  {
 +       struct isp_csi2_device *csi2 = v4l2_get_subdevdata(csi2_subdev);
 +       struct isp_pipeline *pipe = to_isp_pipeline(csi2_subdev-entity);
 +       struct isp_v4l2_subdevs_group *subdevs = pipe-external-host_priv;
 +       struct isp_csiphy_dphy_cfg csi2phy;
 +       int csi2_ddrclk_khz;
 +       struct isp_csiphy_lanes_cfg *lanes;
        unsigned int used_lanes = 0;
        unsigned int i;

 +       if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1
 +           || subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
 +               lanes = subdevs-bus.ccp2.lanecfg;
 +       else
 +               lanes = subdevs-bus.csi2.lanecfg;
 +
 +       /* FIXME: Do 34xx / 35xx require something here? */
 +       if (cpu_is_omap3630()) {
 +               u32 cam_phy_ctrl = omap_readl(
 +                       OMAP343X_CTRL_BASE + 
 OMAP3630_CONTROL_CAMERA_PHY_CTRL);

 How about:
               u32 cam_phy_ctrl = 
 omap_ctrl_readl(OMAP3630_CONTROL_CAMERA_PHY_CTRL);
 ?

 Fine for me.

 +
 +               /*
 +                * SCM.CONTROL_CAMERA_PHY_CTRL
 +                * - bit[4]    : CSIPHY1 data sent to CSIB
 +                * - bit [3:2] : CSIPHY1 config: 00 d-phy, 01/10 ccp2
 +                * - bit [1:0] : CSIPHY2 config: 00 d-phy, 01/10 ccp2
 +                */
 +               if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1)
 +                       cam_phy_ctrl |= 1  2;
 +               else if (subdevs-interface == ISP_INTERFACE_CSI2C_PHY1)
 +                       cam_phy_ctrl = 1  2;

 Shouldn't this be:
                        cam_phy_ctrl = ~(1  2);
 ?

 Probably yes. This has come directly as it was in the original board
 code and might not be entirely correct. It works on the N9 at least.

 +
 +               if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
 +                       cam_phy_ctrl |= 1;
 +               else if (subdevs-interface == ISP_INTERFACE_CSI2A_PHY2)
 +                       cam_phy_ctrl = 1;

 ... and:
                        cam_phy_ctrl = ~1

Re: [PATCH v2 27/31] omap3isp: Configure CSI-2 phy based on platform data

2012-02-09 Thread Aguirre, Sergio
Hi Sakari,

On Thu, Feb 2, 2012 at 5:54 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
 Configure CSI-2 phy based on platform data in the ISP driver. For that, the
 new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same
 was configured from the board code.

 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 ---
  drivers/media/video/omap3isp/ispcsi2.c   |   10 +++-
  drivers/media/video/omap3isp/ispcsiphy.c |   78 
 ++
  drivers/media/video/omap3isp/ispcsiphy.h |    2 +
  3 files changed, 78 insertions(+), 12 deletions(-)

 diff --git a/drivers/media/video/omap3isp/ispcsi2.c 
 b/drivers/media/video/omap3isp/ispcsi2.c
 index 9313f7c..e2e3d63 100644
 --- a/drivers/media/video/omap3isp/ispcsi2.c
 +++ b/drivers/media/video/omap3isp/ispcsi2.c
 @@ -1068,7 +1068,13 @@ static int csi2_set_stream(struct v4l2_subdev *sd, int 
 enable)
        struct isp_video *video_out = csi2-video_out;

        switch (enable) {
 -       case ISP_PIPELINE_STREAM_CONTINUOUS:
 +       case ISP_PIPELINE_STREAM_CONTINUOUS: {
 +               int ret;
 +
 +               ret = omap3isp_csiphy_config(isp, sd);
 +               if (ret  0)
 +                       return ret;
 +
                if (omap3isp_csiphy_acquire(csi2-phy)  0)
                        return -ENODEV;
                csi2-use_fs_irq = pipe-do_propagation;
 @@ -1092,7 +1098,7 @@ static int csi2_set_stream(struct v4l2_subdev *sd, int 
 enable)
                csi2_if_enable(isp, csi2, 1);
                isp_video_dmaqueue_flags_clr(video_out);
                break;
 -
 +       }
        case ISP_PIPELINE_STREAM_STOPPED:
                if (csi2-state == ISP_PIPELINE_STREAM_STOPPED)
                        return 0;
 diff --git a/drivers/media/video/omap3isp/ispcsiphy.c 
 b/drivers/media/video/omap3isp/ispcsiphy.c
 index 5be37ce..5d7a6ab 100644
 --- a/drivers/media/video/omap3isp/ispcsiphy.c
 +++ b/drivers/media/video/omap3isp/ispcsiphy.c
 @@ -28,6 +28,8 @@
  #include linux/device.h
  #include linux/regulator/consumer.h

 +#include ../../../../arch/arm/mach-omap2/control.h
 +
  #include isp.h
  #include ispreg.h
  #include ispcsiphy.h
 @@ -138,15 +140,73 @@ static void csiphy_dphy_config(struct isp_csiphy *phy)
        isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG1);
  }

 -static int csiphy_config(struct isp_csiphy *phy,
 -                        struct isp_csiphy_dphy_cfg *dphy,
 -                        struct isp_csiphy_lanes_cfg *lanes)
 +/*
 + * TCLK values are OK at their reset values
 + */
 +#define TCLK_TERM      0
 +#define TCLK_MISS      1
 +#define TCLK_SETTLE    14
 +
 +int omap3isp_csiphy_config(struct isp_device *isp,
 +                          struct v4l2_subdev *csi2_subdev)
  {
 +       struct isp_csi2_device *csi2 = v4l2_get_subdevdata(csi2_subdev);
 +       struct isp_pipeline *pipe = to_isp_pipeline(csi2_subdev-entity);
 +       struct isp_v4l2_subdevs_group *subdevs = pipe-external-host_priv;
 +       struct isp_csiphy_dphy_cfg csi2phy;
 +       int csi2_ddrclk_khz;
 +       struct isp_csiphy_lanes_cfg *lanes;
        unsigned int used_lanes = 0;
        unsigned int i;

 +       if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1
 +           || subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
 +               lanes = subdevs-bus.ccp2.lanecfg;
 +       else
 +               lanes = subdevs-bus.csi2.lanecfg;
 +
 +       /* FIXME: Do 34xx / 35xx require something here? */
 +       if (cpu_is_omap3630()) {
 +               u32 cam_phy_ctrl = omap_readl(
 +                       OMAP343X_CTRL_BASE + 
 OMAP3630_CONTROL_CAMERA_PHY_CTRL);

How about:
u32 cam_phy_ctrl = 
omap_ctrl_readl(OMAP3630_CONTROL_CAMERA_PHY_CTRL);
?

 +
 +               /*
 +                * SCM.CONTROL_CAMERA_PHY_CTRL
 +                * - bit[4]    : CSIPHY1 data sent to CSIB
 +                * - bit [3:2] : CSIPHY1 config: 00 d-phy, 01/10 ccp2
 +                * - bit [1:0] : CSIPHY2 config: 00 d-phy, 01/10 ccp2
 +                */
 +               if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1)
 +                       cam_phy_ctrl |= 1  2;
 +               else if (subdevs-interface == ISP_INTERFACE_CSI2C_PHY1)
 +                       cam_phy_ctrl = 1  2;

Shouldn't this be:
                       cam_phy_ctrl = ~(1  2);
?

 +
 +               if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
 +                       cam_phy_ctrl |= 1;
 +               else if (subdevs-interface == ISP_INTERFACE_CSI2A_PHY2)
 +                       cam_phy_ctrl = 1;

... and:
                       cam_phy_ctrl = ~1;

 +
 +               omap_writel(cam_phy_ctrl,
 +                           OMAP343X_CTRL_BASE
 +                           + OMAP3630_CONTROL_CAMERA_PHY_CTRL);

Again:
omap_ctrl_writel(cam_phy_ctrl, 
OMAP3630_CONTROL_CAMERA_PHY_CTRL);


 +       }
 +
 +       csi2_ddrclk_khz = pipe-external_rate / 1000
 +               / (2 * csi2-phy-num_data_lanes)
 +               * 

Re: [PATCH v2 03/11] v4l: Introduce sensor operation for getting interface configuration

2011-12-02 Thread Aguirre, Sergio
Hi Stan,

On Fri, Dec 2, 2011 at 7:32 AM, Stanimir Varbanov svarba...@mm-sol.com wrote:
 Hi, Sergio

 This change in interface is not used from the omap4iss driver.

 You could drop it from the patch set, if so.

Oops, yes... I used to depend on this for my soc_camera implementation before...

You're absolutely right, i'll remove it in the next iteration.

Merci!


 On 12/01/2011 02:14 AM, Sergio Aguirre wrote:
 From: Stanimir Varbanov svarba...@mm-sol.com

 Introduce g_interface_parms sensor operation for getting sensor
 interface parameters. These parameters are needed from the host side
 to determine it's own configuration.

 Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
 ---
  include/media/v4l2-subdev.h |   42 
 ++
  1 files changed, 42 insertions(+), 0 deletions(-)

 diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
 index f0f3358..0d322ed 100644
 --- a/include/media/v4l2-subdev.h
 +++ b/include/media/v4l2-subdev.h
 @@ -362,6 +362,42 @@ struct v4l2_subdev_vbi_ops {
       int (*s_sliced_fmt)(struct v4l2_subdev *sd, struct 
 v4l2_sliced_vbi_format *fmt);
  };

 +/* Which interface the sensor use to provide it's image data */
 +enum v4l2_subdev_sensor_iface {
 +     V4L2_SUBDEV_SENSOR_PARALLEL,
 +     V4L2_SUBDEV_SENSOR_SERIAL,
 +};
 +
 +/* Each interface could use the following modes */
 +/* Image sensor provides horizontal and vertical sync signals */
 +#define V4L2_SUBDEV_SENSOR_MODE_PARALLEL_SYNC        0
 +/* BT.656 interface. Embedded sync */
 +#define V4L2_SUBDEV_SENSOR_MODE_PARALLEL_ITU 1
 +/* MIPI CSI1 */
 +#define V4L2_SUBDEV_SENSOR_MODE_SERIAL_CSI1  2
 +/* MIPI CSI2 */
 +#define V4L2_SUBDEV_SENSOR_MODE_SERIAL_CSI2  3
 +
 +struct v4l2_subdev_sensor_serial_parms {
 +     unsigned char lanes;            /* number of lanes used */
 +     unsigned char channel;          /* virtual channel */
 +     unsigned int phy_rate;          /* output rate at CSI phy in bps */
 +     unsigned int pix_clk;           /* pixel clock in Hz */
 +};
 +
 +struct v4l2_subdev_sensor_parallel_parms {
 +     unsigned int pix_clk;           /* pixel clock in Hz */
 +};
 +
 +struct v4l2_subdev_sensor_interface_parms {
 +     enum v4l2_subdev_sensor_iface if_type;
 +     unsigned int if_mode;
 +     union {
 +             struct v4l2_subdev_sensor_serial_parms serial;
 +             struct v4l2_subdev_sensor_parallel_parms parallel;
 +     } parms;
 +};
 +
  /**
   * struct v4l2_subdev_sensor_ops - v4l2-subdev sensor operations
   * @g_skip_top_lines: number of lines at the top of the image to be skipped.
 @@ -371,10 +407,16 @@ struct v4l2_subdev_vbi_ops {
   * @g_skip_frames: number of frames to skip at stream start. This is needed 
 for
   *              buggy sensors that generate faulty frames when they are
   *              turned on.
 + * @g_interface_parms: get sensor interface parameters. The sensor subdev 
 should
 + *                  fill this structure with current interface params. These
 + *                  interface parameters are needed on host side to 
 configure
 + *                  it's own hardware receivers.
   */
  struct v4l2_subdev_sensor_ops {
       int (*g_skip_top_lines)(struct v4l2_subdev *sd, u32 *lines);
       int (*g_skip_frames)(struct v4l2_subdev *sd, u32 *frames);
 +     int (*g_interface_parms)(struct v4l2_subdev *sd,
 +                     struct v4l2_subdev_sensor_interface_parms *parms);
  };

  /*


 --
 best regards,
 Stan
--
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: [RFC PATCH v1 2/7] omap4: build fdif omap device from hwmod

2011-12-02 Thread Aguirre, Sergio
Hi Ming,

Thanks for the patches.

On Fri, Dec 2, 2011 at 9:02 AM, Ming Lei ming@canonical.com wrote:
 Signed-off-by: Ming Lei ming@canonical.com
 ---
  arch/arm/mach-omap2/devices.c |   33 +
  1 files changed, 33 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
 index 1166bdc..a392af5 100644
 --- a/arch/arm/mach-omap2/devices.c
 +++ b/arch/arm/mach-omap2/devices.c
 @@ -728,6 +728,38 @@ void __init omap242x_init_mmc(struct 
 omap_mmc_platform_data **mmc_data)

  #endif

 +static struct platform_device* __init omap4_init_fdif(void)
 +{
 +       int id = -1;

You could remove this , as it is being used only once, and never changed.

 +       struct platform_device *pd;
 +       struct omap_hwmod *oh;
 +       const char *dev_name = fdif;
 +
 +       oh = omap_hwmod_lookup(fdif);
 +       if (!oh) {
 +               pr_err(Could not look up fdif hwmod\n);
 +               return NULL;
 +       }
 +
 +       pd = omap_device_build(dev_name, id, oh, NULL, 0, NULL, 0, 0);

Just do:

pd = omap_device_build(dev_name, -1, oh, NULL, 0, NULL, 0, 0);

 +       WARN(IS_ERR(pd), Can't build omap_device for %s.\n,
 +                               dev_name);
 +       return pd;
 +}
 +
 +static void __init omap_init_fdif(void)
 +{
 +       if (cpu_is_omap44xx()) {
 +               struct platform_device *pd;
 +
 +               pd = omap4_init_fdif();
 +               if (!pd)
 +                       return;
 +
 +               pm_runtime_enable(pd-dev);
 +       }
 +}

IMHO, you could reduce 1 level of indentation here, like this:

static void __init omap_init_fdif(void)
{
struct platform_device *pd;

if (!cpu_is_omap44xx())
return;

pd = omap4_init_fdif();
if (!pd)
return;

pm_runtime_enable(pd-dev);
}

Regards,
Sergio

 +
  /*-*/

  #if defined(CONFIG_HDQ_MASTER_OMAP) || defined(CONFIG_HDQ_MASTER_OMAP_MODULE)
 @@ -808,6 +840,7 @@ static int __init omap2_init_devices(void)
        omap_init_sham();
        omap_init_aes();
        omap_init_vout();
 +       omap_init_fdif();

        return 0;
  }
 --
 1.7.5.4

 --
 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
--
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: [PATCH v2 04/11] OMAP4: hwmod: Include CSI2A and CSIPHY1 memory sections

2011-12-02 Thread Aguirre, Sergio
Hi Kevin,

Thanks for the review.

On Fri, Dec 2, 2011 at 4:49 PM, Kevin Hilman khil...@ti.com wrote:
 +Benoit,

 Aguirre, Sergio saagui...@ti.com writes:

 Hi Vaibhav,

 Thanks for the comments.

 On Thu, Dec 1, 2011 at 12:34 AM, Hiremath, Vaibhav hvaib...@ti.com wrote:

 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio
 Sent: Thursday, December 01, 2011 5:45 AM
 To: linux-media@vger.kernel.org
 Cc: linux-o...@vger.kernel.org; laurent.pinch...@ideasonboard.com;
 sakari.ai...@iki.fi; Aguirre, Sergio
 Subject: [PATCH v2 04/11] OMAP4: hwmod: Include CSI2A and CSIPHY1 memory
 sections

 Signed-off-by: Sergio Aguirre saagui...@ti.com
 ---
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   16 +---
  1 files changed, 13 insertions(+), 3 deletions(-)

 diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-
 omap2/omap_hwmod_44xx_data.c
 index 7695e5d..1b59e2f 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 @@ -2623,8 +2623,18 @@ static struct omap_hwmod_ocp_if
 *omap44xx_iss_masters[] = {

  static struct omap_hwmod_addr_space omap44xx_iss_addrs[] = {
       {
 -             .pa_start       = 0x5200,
 -             .pa_end         = 0x52ff,
 +             .pa_start       = OMAP44XX_ISS_TOP_BASE,
 +             .pa_end         = OMAP44XX_ISS_TOP_END,
 +             .flags          = ADDR_TYPE_RT
 +     },
 +     {
 +             .pa_start       = OMAP44XX_ISS_CSI2_A_REGS1_BASE,
 +             .pa_end         = OMAP44XX_ISS_CSI2_A_REGS1_END,
 +             .flags          = ADDR_TYPE_RT
 +     },
 +     {
 +             .pa_start       = OMAP44XX_ISS_CAMERARX_CORE1_BASE,
 +             .pa_end         = OMAP44XX_ISS_CAMERARX_CORE1_END,
               .flags          = ADDR_TYPE_RT
       },
 This patch will result in build failure, because, the above base addresses
 are getting defined in the next patch

 [PATCH v2 05/11] OMAP4: Add base addresses for ISS

 Agreed. Will revisit git-bisectability of the patch series. Will fix.

 To fix this, just drop the #defines from the header, and use raw
 addresses directly.

Ok, i'll drop patch #5 in this series.


 Also, work with Benoit to make sure at the scripts that autogenerate
 this data are updated to include these two regions.

Ok.

As a side note, I might need more addresses for the rest of the ISP
components later on. I'll enable more subsystems once the CSI2-A only
initial version is in an acceptable state.

Regards,
Sergio


 Kevin
--
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: [PATCH v2 05/11] OMAP4: Add base addresses for ISS

2011-12-02 Thread Aguirre, Sergio
Hi Kevin,

Thanks for the review.

On Fri, Dec 2, 2011 at 4:45 PM, Kevin Hilman khil...@ti.com wrote:
 Sergio Aguirre saagui...@ti.com writes:

 NOTE: This isn't the whole list of features that the
 ISS supports, but the only ones supported at the moment.

 Signed-off-by: Sergio Aguirre saagui...@ti.com

 [...]

 diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h 
 b/arch/arm/plat-omap/include/plat/omap44xx.h
 index ea2b8a6..31432aa 100644
 --- a/arch/arm/plat-omap/include/plat/omap44xx.h
 +++ b/arch/arm/plat-omap/include/plat/omap44xx.h
 @@ -49,6 +49,15 @@
  #define OMAP44XX_MAILBOX_BASE                (L4_44XX_BASE + 0xF4000)
  #define OMAP44XX_HSUSB_OTG_BASE              (L4_44XX_BASE + 0xAB000)

 +#define OMAP44XX_ISS_BASE                    0x5200
 +#define OMAP44XX_ISS_TOP_BASE                        (OMAP44XX_ISS_BASE + 
 0x0)
 +#define OMAP44XX_ISS_CSI2_A_REGS1_BASE               (OMAP44XX_ISS_BASE + 
 0x1000)
 +#define OMAP44XX_ISS_CAMERARX_CORE1_BASE     (OMAP44XX_ISS_BASE + 0x1170)
 +
 +#define OMAP44XX_ISS_TOP_END                 (OMAP44XX_ISS_TOP_BASE + 256 - 
 1)
 +#define OMAP44XX_ISS_CSI2_A_REGS1_END                
 (OMAP44XX_ISS_CSI2_A_REGS1_BASE + 368 - 1)
 +#define OMAP44XX_ISS_CAMERARX_CORE1_END              
 (OMAP44XX_ISS_CAMERARX_CORE1_BASE + 32 - 1)
 +
  #define OMAP4_MMU1_BASE                      0x55082000
  #define OMAP4_MMU2_BASE                      0x4A066000

 Who are the users of thes address ranges?

 IMO, we shouldn't ned to add anymore based address definitions.  These
 should be done in the hwmod data, and drivers get base addresses using
 the standard ways of getting resources (DT or platform_get_resource())

I see... I get your point now.

Will remove them from this patch series then.

Regards,
Sergio


 Kevin
--
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: [PATCH v2 04/11] OMAP4: hwmod: Include CSI2A and CSIPHY1 memory sections

2011-12-01 Thread Aguirre, Sergio
Hi Vaibhav,

Thanks for the comments.

On Thu, Dec 1, 2011 at 12:34 AM, Hiremath, Vaibhav hvaib...@ti.com wrote:

 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio
 Sent: Thursday, December 01, 2011 5:45 AM
 To: linux-media@vger.kernel.org
 Cc: linux-o...@vger.kernel.org; laurent.pinch...@ideasonboard.com;
 sakari.ai...@iki.fi; Aguirre, Sergio
 Subject: [PATCH v2 04/11] OMAP4: hwmod: Include CSI2A and CSIPHY1 memory
 sections

 Signed-off-by: Sergio Aguirre saagui...@ti.com
 ---
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   16 +---
  1 files changed, 13 insertions(+), 3 deletions(-)

 diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-
 omap2/omap_hwmod_44xx_data.c
 index 7695e5d..1b59e2f 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 @@ -2623,8 +2623,18 @@ static struct omap_hwmod_ocp_if
 *omap44xx_iss_masters[] = {

  static struct omap_hwmod_addr_space omap44xx_iss_addrs[] = {
       {
 -             .pa_start       = 0x5200,
 -             .pa_end         = 0x52ff,
 +             .pa_start       = OMAP44XX_ISS_TOP_BASE,
 +             .pa_end         = OMAP44XX_ISS_TOP_END,
 +             .flags          = ADDR_TYPE_RT
 +     },
 +     {
 +             .pa_start       = OMAP44XX_ISS_CSI2_A_REGS1_BASE,
 +             .pa_end         = OMAP44XX_ISS_CSI2_A_REGS1_END,
 +             .flags          = ADDR_TYPE_RT
 +     },
 +     {
 +             .pa_start       = OMAP44XX_ISS_CAMERARX_CORE1_BASE,
 +             .pa_end         = OMAP44XX_ISS_CAMERARX_CORE1_END,
               .flags          = ADDR_TYPE_RT
       },
 This patch will result in build failure, because, the above base addresses
 are getting defined in the next patch

 [PATCH v2 05/11] OMAP4: Add base addresses for ISS

Agreed. Will revisit git-bisectability of the patch series. Will fix.

Regards,
Sergio


 Thanks,
 Vaibhav

       { }
 @@ -5350,7 +5360,7 @@ static __initdata struct omap_hwmod
 *omap44xx_hwmods[] = {
       omap44xx_ipu_c1_hwmod,

       /* iss class */
 -/*   omap44xx_iss_hwmod, */
 +     omap44xx_iss_hwmod,

       /* iva class */
       omap44xx_iva_hwmod,
 --
 1.7.7.4

 --
 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
--
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: [PATCH v2 10/11] arm: omap4panda: Add support for omap4iss camera

2011-12-01 Thread Aguirre, Sergio
Hi Vaibhav,

Thanks for the comments.

On Thu, Dec 1, 2011 at 12:24 AM, Hiremath, Vaibhav hvaib...@ti.com wrote:

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio
 Sent: Thursday, December 01, 2011 5:45 AM
 To: linux-media@vger.kernel.org
 Cc: linux-o...@vger.kernel.org; laurent.pinch...@ideasonboard.com;
 sakari.ai...@iki.fi; Aguirre, Sergio
 Subject: [PATCH v2 10/11] arm: omap4panda: Add support for omap4iss camera

 This adds support for camera interface with the support for
 following sensors:

 - OV5640
 - OV5650

 Signed-off-by: Sergio Aguirre saagui...@ti.com
 ---
  arch/arm/mach-omap2/Kconfig                   |   27 
  arch/arm/mach-omap2/Makefile                  |    1 +
  arch/arm/mach-omap2/board-omap4panda-camera.c |  198
 +
  3 files changed, 226 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c

 diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
 index f883abb..0fc5ce9 100644
 --- a/arch/arm/mach-omap2/Kconfig
 +++ b/arch/arm/mach-omap2/Kconfig
 @@ -358,6 +358,33 @@ config MACH_OMAP4_PANDA
       select OMAP_PACKAGE_CBS
       select REGULATOR_FIXED_VOLTAGE

 +config MACH_OMAP4_PANDA_CAMERA_SUPPORT
 +     bool OMAP4 Panda Board Camera support
 +     depends on MACH_OMAP4_PANDA
 +     select MEDIA_SUPPORT
 +     select MEDIA_CONTROLLER
 +     select VIDEO_DEV
 +     select VIDEO_V4L2_SUBDEV_API
 +     select VIDEO_OMAP4
 +     help
 +       Enable Camera HW support for PandaBoard.
 +       This is for using the OMAP4 ISS CSI2A Camera sensor
 +       interface.
 +
 +choice
 +     prompt Camera sensor to use
 +     depends on MACH_OMAP4_PANDA_CAMERA_SUPPORT
 +     default MACH_OMAP4_PANDA_CAM_OV5650
 +
 +     config MACH_OMAP4_PANDA_CAM_OV5640
 +             bool Use OmniVision OV5640 Camera
 +             select VIDEO_OV5640
 +
 +     config MACH_OMAP4_PANDA_CAM_OV5650
 +             bool Use OmniVision OV5650 Camera
 +             select VIDEO_OV5650
 +endchoice
 +
  config OMAP3_EMU
       bool OMAP3 debugging peripherals
       depends on ARCH_OMAP3
 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
 index 8bc446a..e80724d 100644
 --- a/arch/arm/mach-omap2/Makefile
 +++ b/arch/arm/mach-omap2/Makefile
 @@ -236,6 +236,7 @@ obj-$(CONFIG_MACH_TI8168EVM)              += board-
 ti8168evm.o
  # Platform specific device init code

  obj-$(CONFIG_MACH_OMAP_4430SDP_CAMERA_SUPPORT)       += 
 board-4430sdp-camera.o
 +obj-$(CONFIG_MACH_OMAP4_PANDA_CAMERA_SUPPORT)        += board-omap4panda-
 camera.o

 Can't this be merged into single file? Do we really need separate file for 
 every board here?

 I am sure you would have thought about this.

:)

Well, not really, to be honest.

I could have a single file, but wouldn't that make it more complex?

I mean, every board has it's own HW connection specs, like sensor MCLK source,
and different power up sequences. How would you probe for all, without messing
with an invalid GPIO on that board?

Have you resolved a similar case for other OMAP/Davinci boards?


  omap-flash-$(CONFIG_MTD_NAND_OMAP2)  := board-flash.o
  omap-flash-$(CONFIG_MTD_ONENAND_OMAP2)       := board-flash.o
 diff --git a/arch/arm/mach-omap2/board-omap4panda-camera.c
 b/arch/arm/mach-omap2/board-omap4panda-camera.c
 new file mode 100644
 index 000..02ef36e
 --- /dev/null
 +++ b/arch/arm/mach-omap2/board-omap4panda-camera.c
 @@ -0,0 +1,198 @@
 +#include linux/gpio.h
 +#include linux/clk.h
 +#include linux/delay.h
 +
 +#include plat/i2c.h
 +#include plat/omap-pm.h
 +
 +#include asm/mach-types.h
 +
 +#include media/ov5640.h
 +#include media/ov5650.h
 +
 +#include devices.h
 +#include ../../../drivers/media/video/omap4iss/iss.h
 +
 I believe this is not good practice to include files directly from drivers 
 folder. You should divide the header file such that, driver specific 
 information stays in driver/... and platform specific goes into include/...

Right. Will fix.


 +#include control.h
 +#include mux.h
 +
 +#define PANDA_GPIO_CAM_PWRDN         45
 +#define PANDA_GPIO_CAM_RESET         83
 +
 +static struct clk *panda_cam_aux_clk;
 +
 +static int panda_ov5640_power(struct v4l2_subdev *subdev, int on)
 +{
 +     struct iss_device *iss = v4l2_dev_to_iss_device(subdev-v4l2_dev);
 +     int ret = 0;
 You are not using this variable at all, you can get rid of this.

Right. Will fix.


 +     struct iss_csiphy_dphy_cfg dphy;
 +     struct iss_csiphy_lanes_cfg lanes;
 +     unsigned int ddr_freq = 480; /* FIXME: Do an actual query for this
 */
 +
 +     memset(lanes, 0, sizeof(lanes));
 +     memset(dphy, 0, sizeof(dphy));
 +
 +     lanes.clk.pos = 1;
 +     lanes.clk.pol = 0;
 +     lanes.data[0].pos = 2;
 +     lanes.data[0].pol = 0;
 +     lanes.data[1].pos = 3;
 +     lanes.data[1].pol = 0;
 +
 +     dphy.ths_term = 12500 * ddr_freq + 100) / 100) - 1) 
 0xFF

Re: [PATCH v2 05/11] OMAP4: Add base addresses for ISS

2011-12-01 Thread Aguirre, Sergio
Hi Laurent,

Thanks for the review.

On Thu, Dec 1, 2011 at 11:24 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Sergio,

 On Thursday 01 December 2011 01:14:54 Sergio Aguirre wrote:
 NOTE: This isn't the whole list of features that the
 ISS supports, but the only ones supported at the moment.

 Signed-off-by: Sergio Aguirre saagui...@ti.com
 ---
  arch/arm/mach-omap2/devices.c              |   32
  arch/arm/plat-omap/include/plat/omap44xx.h |
   9 +++
  2 files changed, 41 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
 index c15cfad..b48aeea 100644
 --- a/arch/arm/mach-omap2/devices.c
 +++ b/arch/arm/mach-omap2/devices.c
 @@ -32,6 +32,7 @@
  #include plat/omap_hwmod.h
  #include plat/omap_device.h
  #include plat/omap4-keypad.h
 +#include plat/omap4-iss.h

 I try to keep headers sorted alphabetically when possible, but that might just
 be me.

No problem. I can change it.



  #include mux.h
  #include control.h
 @@ -217,6 +218,37 @@ int omap3_init_camera(struct isp_platform_data *pdata)
       return platform_device_register(omap3isp_device);
  }

 +int omap4_init_camera(struct iss_platform_data *pdata, struct
 omap_board_data *bdata)
 +{
 +     struct platform_device *pdev;
 +     struct omap_hwmod *oh;
 +     struct iss_platform_data *omap4iss_pdata;
 +     char *oh_name = iss;
 +     char *name = omap4iss;

 Would const char or static const char help the compiler putting the strings to
 a read-only section ?

Right. Will fix.


 +     unsigned int id = -1;
 +
 +     oh = omap_hwmod_lookup(oh_name);
 +     if (!oh) {
 +             pr_err(Could not look up %s\n, oh_name);
 +             return -ENODEV;
 +     }
 +
 +     omap4iss_pdata = pdata;
 +
 +     pdev = omap_device_build(name, id, oh, omap4iss_pdata,
 +                     sizeof(struct iss_platform_data), NULL, 0, 0);

 This is the only location where id is used, maybe you could pass -1 directly
 to the function ?

Ditto.

Thanks and regards,
Sergio


 +
 +     if (IS_ERR(pdev)) {
 +             WARN(1, Can't build omap_device for %s:%s.\n,
 +                                             name, oh-name);
 +             return PTR_ERR(pdev);
 +     }
 +
 +     oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt);
 +
 +     return 0;
 +}
 +
  static inline void omap_init_camera(void)
  {
  #if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
 diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h
 b/arch/arm/plat-omap/include/plat/omap44xx.h index ea2b8a6..31432aa 100644
 --- a/arch/arm/plat-omap/include/plat/omap44xx.h
 +++ b/arch/arm/plat-omap/include/plat/omap44xx.h
 @@ -49,6 +49,15 @@
  #define OMAP44XX_MAILBOX_BASE                (L4_44XX_BASE + 0xF4000)
  #define OMAP44XX_HSUSB_OTG_BASE              (L4_44XX_BASE + 0xAB000)

 +#define OMAP44XX_ISS_BASE                    0x5200
 +#define OMAP44XX_ISS_TOP_BASE                        (OMAP44XX_ISS_BASE + 
 0x0)
 +#define OMAP44XX_ISS_CSI2_A_REGS1_BASE               (OMAP44XX_ISS_BASE + 
 0x1000)
 +#define OMAP44XX_ISS_CAMERARX_CORE1_BASE     (OMAP44XX_ISS_BASE + 0x1170)
 +
 +#define OMAP44XX_ISS_TOP_END                 (OMAP44XX_ISS_TOP_BASE + 256 - 
 1)
 +#define OMAP44XX_ISS_CSI2_A_REGS1_END                
 (OMAP44XX_ISS_CSI2_A_REGS1_BASE +
 368 - 1) +#define
 OMAP44XX_ISS_CAMERARX_CORE1_END               
 (OMAP44XX_ISS_CAMERARX_CORE1_BASE + 32 -
 1) +
  #define OMAP4_MMU1_BASE                      0x55082000
  #define OMAP4_MMU2_BASE                      0x4A066000

 --
 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: [PATCH v2 02/11] mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value

2011-12-01 Thread Aguirre, Sergio
Hi Laurent,

Thanks for the review.

On Thu, Dec 1, 2011 at 11:24 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Sergio,

 On Thursday 01 December 2011 01:14:51 Sergio Aguirre wrote:
 The define should be the result of 1  Bit number.

 Bit number for GPOCTL.GPO3 field is 2, which results
 in 0x4 value.

 Signed-off-by: Sergio Aguirre saagui...@ti.com
 ---
  include/linux/mfd/twl6040.h |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h
 index 2463c261..2a7ff16 100644
 --- a/include/linux/mfd/twl6040.h
 +++ b/include/linux/mfd/twl6040.h
 @@ -142,7 +142,7 @@

  #define TWL6040_GPO1                 0x01
  #define TWL6040_GPO2                 0x02
 -#define TWL6040_GPO3                 0x03
 +#define TWL6040_GPO3                 0x04

 What about defining the fields as (1  x) instead then ?

I thought about that, but I guess I just wanted to keep it
consistent with the rest of the file.

Maybe I can create a separate patch for changing all these bitwise
flags to use BIT() macros instead.

Thanks and Regards,
Sergio



  /* ACCCTL (0x2D) fields */

 --
 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: [PATCH v2 00/11] v4l2: OMAP4 ISS driver + Sensor + Board support

2011-12-01 Thread Aguirre, Sergio
Hi Sakari,

On Thu, Dec 1, 2011 at 10:14 AM, Sakari Ailus sakari.ai...@iki.fi wrote:
 Hi Sergio,

 Thanks for the patchset!!

And thanks for your attention :)


 On Wed, Nov 30, 2011 at 06:14:49PM -0600, Sergio Aguirre wrote:
 Hi everyone,

 This is the second version of the OMAP4 ISS driver,
 now ported to the Media Controller framework AND supporting
 videobuf2 framework.

 This patchset should apply cleanly on top of v3.2-rc3 kernel tag.

 This driver attempts to provide an fully open source solution to
 control the OMAP4 Imaging SubSystem (a.k.a. ISS).

 Starts with just CSI2-A interface support, and pretends to be
 ready for expansion to add support to the many ISS block modules
 as possible.

 Please see newly added documentation for more details:

 Documentation/video4linux/omap4_camera.txt

 I propose s/omap4_camera/omap4iss/, according to the path name in the
 drivers/media/video directory.

Makes sense. Will fix.


 Any comments/complaints are welcome. :)

 Changes since v1:
 - Simplification of auxclk handling in board files. (Pointed out by: Roger 
 Quadros)
 - Cleanup of Camera support enablement for 4430sdp  panda. (Pointed out by: 
 Roger Quadros)
 - Use of HWMOD declaration for assisted platform_device creation. (Pointed 
 out by: Felipe Balbi)
 - Videobuf2 migration (Removal of custom iss_queue buffer handling driver)

 I'm happy to see it's using videobuf2!

Yeah, I'll definitely need it for multi-planar buffer handling for
NV12 buffer capturing.

Resizer can color convert from YUV422-YUV420 NV12 now, and expects 2 pointers
(1 for Y, and 1 for UV 2x2 sampled) to be programmed in HW.


 I have no other comments quite yet. :-)

Ok, let me know if you find something eye-popping ugly in there. I'll
be happy to fix it. :)

Thanks and Regards,
Sergio


 Cheers,

 --
 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: [PATCH v2 00/11] v4l2: OMAP4 ISS driver + Sensor + Board support

2011-12-01 Thread Aguirre, Sergio
Hi Laurent,

On Thu, Dec 1, 2011 at 11:26 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Sergio,

 On Thursday 01 December 2011 01:14:49 Sergio Aguirre wrote:
 Hi everyone,

 This is the second version of the OMAP4 ISS driver,
 now ported to the Media Controller framework AND supporting
 videobuf2 framework.

 Thanks a lot for working on this.

And thanks to you for the patience and interest. I hope to make faster
updates from now on :)


 This patchset should apply cleanly on top of v3.2-rc3 kernel tag.

 This driver attempts to provide an fully open source solution to
 control the OMAP4 Imaging SubSystem (a.k.a. ISS).

 Starts with just CSI2-A interface support, and pretends to be
 ready for expansion to add support to the many ISS block modules
 as possible.

 Please see newly added documentation for more details:

 Documentation/video4linux/omap4_camera.txt

 Any comments/complaints are welcome. :)

 I've started reviewing the patches, but it might take some time as I got lots
 on my plate at the moment. I will concentrate on the ISS patch (06/11) first.
 The sensor drivers are needed now for testing purpose, but can get their share
 of love later.

Brilliant! That's fine with me.

Thanks for your time. I really appreciate it.

Regards,
Sergio


 Changes since v1:
 - Simplification of auxclk handling in board files. (Pointed out by: Roger
 Quadros) - Cleanup of Camera support enablement for 4430sdp  panda.
 (Pointed out by: Roger Quadros) - Use of HWMOD declaration for assisted
 platform_device creation. (Pointed out by: Felipe Balbi) - Videobuf2
 migration (Removal of custom iss_queue buffer handling driver) - Proper
 GPO3 handling for CAM_SEL in 4430sdp.

 Sergio Aguirre (10):
   TWL6030: Add mapping for auxiliary regs
   mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value
   OMAP4: hwmod: Include CSI2A and CSIPHY1 memory sections
   OMAP4: Add base addresses for ISS
   v4l: Add support for omap4iss driver
   v4l: Add support for ov5640 sensor
   v4l: Add support for ov5650 sensor
   arm: omap4430sdp: Add support for omap4iss camera
   arm: omap4panda: Add support for omap4iss camera
   arm: Add support for CMA for omap4iss driver

 Stanimir Varbanov (1):
   v4l: Introduce sensor operation for getting interface configuration

  Documentation/video4linux/omap4_camera.txt    |   60 ++
  arch/arm/mach-omap2/Kconfig                   |   54 +
  arch/arm/mach-omap2/Makefile                  |    3 +
  arch/arm/mach-omap2/board-4430sdp-camera.c    |  221 
  arch/arm/mach-omap2/board-omap4panda-camera.c |  198 
  arch/arm/mach-omap2/devices.c                 |   40 +
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c    |   16 +-
  arch/arm/plat-omap/include/plat/omap4-iss.h   |   42 +
  arch/arm/plat-omap/include/plat/omap44xx.h    |    9 +
  drivers/media/video/Kconfig                   |   25 +
  drivers/media/video/Makefile                  |    3 +
  drivers/media/video/omap4iss/Makefile         |    6 +
  drivers/media/video/omap4iss/iss.c            | 1179
 ++ drivers/media/video/omap4iss/iss.h            |
 133 +++
  drivers/media/video/omap4iss/iss_csi2.c       | 1324
 + drivers/media/video/omap4iss/iss_csi2.h       |
 166 +++
  drivers/media/video/omap4iss/iss_csiphy.c     |  215 
  drivers/media/video/omap4iss/iss_csiphy.h     |   69 ++
  drivers/media/video/omap4iss/iss_regs.h       |  238 +
  drivers/media/video/omap4iss/iss_video.c      | 1192
 ++ drivers/media/video/omap4iss/iss_video.h      |
 205 
  drivers/media/video/ov5640.c                  |  972 ++
  drivers/media/video/ov5650.c                  |  524 ++
  drivers/mfd/twl-core.c                        |    2 +-
  include/linux/mfd/twl6040.h                   |    2 +-
  include/media/ov5640.h                        |   10 +
  include/media/ov5650.h                        |   10 +
  include/media/v4l2-chip-ident.h               |    2 +
  include/media/v4l2-subdev.h                   |   42 +
  29 files changed, 6957 insertions(+), 5 deletions(-)
  create mode 100644 Documentation/video4linux/omap4_camera.txt
  create mode 100644 arch/arm/mach-omap2/board-4430sdp-camera.c
  create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c
  create mode 100644 arch/arm/plat-omap/include/plat/omap4-iss.h
  create mode 100644 drivers/media/video/omap4iss/Makefile
  create mode 100644 drivers/media/video/omap4iss/iss.c
  create mode 100644 drivers/media/video/omap4iss/iss.h
  create mode 100644 drivers/media/video/omap4iss/iss_csi2.c
  create mode 100644 drivers/media/video/omap4iss/iss_csi2.h
  create mode 100644 drivers/media/video/omap4iss/iss_csiphy.c
  create mode 100644 drivers/media/video/omap4iss/iss_csiphy.h
  create mode 100644 drivers/media/video/omap4iss/iss_regs.h
  create mode 100644 drivers/media/video/omap4iss/iss_video.c
  create mode 100644 drivers/media/video/omap4iss/iss_video.h
  create mode 100644 

Re: [PATCH v2 01/11] TWL6030: Add mapping for auxiliary regs

2011-12-01 Thread Aguirre, Sergio
Hi Balaji,

Thanks for the review.

On Thu, Dec 1, 2011 at 9:58 AM, T Krishnamoorthy, Balaji
balaj...@ti.com wrote:
 On Thu, Dec 1, 2011 at 5:44 AM, Sergio Aguirre saagui...@ti.com wrote:
 Signed-off-by: Sergio Aguirre saagui...@ti.com
 ---
  drivers/mfd/twl-core.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
 index bfbd660..e26b564 100644
 --- a/drivers/mfd/twl-core.c
 +++ b/drivers/mfd/twl-core.c
 @@ -323,7 +323,7 @@ static struct twl_mapping twl6030_map[] = {
        { SUB_CHIP_ID0, TWL6030_BASEADD_ZERO },
        { SUB_CHIP_ID1, TWL6030_BASEADD_ZERO },

 -       { SUB_CHIP_ID2, TWL6030_BASEADD_ZERO },
 +       { SUB_CHIP_ID1, TWL6030_BASEADD_AUX },

 Instead you can use TWL6030_MODULE_ID1, with base address as
 zero for all registers in auxiliaries register map.

Ok.

I'm actually thinking about this, and in the process on reviewing the
need to access those registers.

I should probably be using the regulator framework to control VAUX3 instead...

Thanks for your inputs.

Regards,
Sergio


        { SUB_CHIP_ID2, TWL6030_BASEADD_ZERO },
        { SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
        { SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
 --
 1.7.7.4

 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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: [PATCH v2 00/11] v4l2: OMAP4 ISS driver + Sensor + Board support

2011-11-30 Thread Aguirre, Sergio
Hi again,

On Wed, Nov 30, 2011 at 6:14 PM, Sergio Aguirre saagui...@ti.com wrote:
 Hi everyone,

 This is the second version of the OMAP4 ISS driver,
 now ported to the Media Controller framework AND supporting
 videobuf2 framework.

 This patchset should apply cleanly on top of v3.2-rc3 kernel tag.

 This driver attempts to provide an fully open source solution to
 control the OMAP4 Imaging SubSystem (a.k.a. ISS).

 Starts with just CSI2-A interface support, and pretends to be
 ready for expansion to add support to the many ISS block modules
 as possible.

 Please see newly added documentation for more details:

 Documentation/video4linux/omap4_camera.txt

 Any comments/complaints are welcome. :)

 Changes since v1:
 - Simplification of auxclk handling in board files. (Pointed out by: Roger 
 Quadros)
 - Cleanup of Camera support enablement for 4430sdp  panda. (Pointed out by: 
 Roger Quadros)
 - Use of HWMOD declaration for assisted platform_device creation. (Pointed 
 out by: Felipe Balbi)
 - Videobuf2 migration (Removal of custom iss_queue buffer handling driver)
 - Proper GPO3 handling for CAM_SEL in 4430sdp.

Also, you can pull this as a branch in my git tree here:

Web URL: http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera

git URL: git://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera.git
Branch: for3.2-rc3

Regards,
Sergio


 Sergio Aguirre (10):
  TWL6030: Add mapping for auxiliary regs
  mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value
  OMAP4: hwmod: Include CSI2A and CSIPHY1 memory sections
  OMAP4: Add base addresses for ISS
  v4l: Add support for omap4iss driver
  v4l: Add support for ov5640 sensor
  v4l: Add support for ov5650 sensor
  arm: omap4430sdp: Add support for omap4iss camera
  arm: omap4panda: Add support for omap4iss camera
  arm: Add support for CMA for omap4iss driver

 Stanimir Varbanov (1):
  v4l: Introduce sensor operation for getting interface configuration

  Documentation/video4linux/omap4_camera.txt    |   60 ++
  arch/arm/mach-omap2/Kconfig                   |   54 +
  arch/arm/mach-omap2/Makefile                  |    3 +
  arch/arm/mach-omap2/board-4430sdp-camera.c    |  221 
  arch/arm/mach-omap2/board-omap4panda-camera.c |  198 
  arch/arm/mach-omap2/devices.c                 |   40 +
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c    |   16 +-
  arch/arm/plat-omap/include/plat/omap4-iss.h   |   42 +
  arch/arm/plat-omap/include/plat/omap44xx.h    |    9 +
  drivers/media/video/Kconfig                   |   25 +
  drivers/media/video/Makefile                  |    3 +
  drivers/media/video/omap4iss/Makefile         |    6 +
  drivers/media/video/omap4iss/iss.c            | 1179 ++
  drivers/media/video/omap4iss/iss.h            |  133 +++
  drivers/media/video/omap4iss/iss_csi2.c       | 1324 
 +
  drivers/media/video/omap4iss/iss_csi2.h       |  166 +++
  drivers/media/video/omap4iss/iss_csiphy.c     |  215 
  drivers/media/video/omap4iss/iss_csiphy.h     |   69 ++
  drivers/media/video/omap4iss/iss_regs.h       |  238 +
  drivers/media/video/omap4iss/iss_video.c      | 1192 ++
  drivers/media/video/omap4iss/iss_video.h      |  205 
  drivers/media/video/ov5640.c                  |  972 ++
  drivers/media/video/ov5650.c                  |  524 ++
  drivers/mfd/twl-core.c                        |    2 +-
  include/linux/mfd/twl6040.h                   |    2 +-
  include/media/ov5640.h                        |   10 +
  include/media/ov5650.h                        |   10 +
  include/media/v4l2-chip-ident.h               |    2 +
  include/media/v4l2-subdev.h                   |   42 +
  29 files changed, 6957 insertions(+), 5 deletions(-)
  create mode 100644 Documentation/video4linux/omap4_camera.txt
  create mode 100644 arch/arm/mach-omap2/board-4430sdp-camera.c
  create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c
  create mode 100644 arch/arm/plat-omap/include/plat/omap4-iss.h
  create mode 100644 drivers/media/video/omap4iss/Makefile
  create mode 100644 drivers/media/video/omap4iss/iss.c
  create mode 100644 drivers/media/video/omap4iss/iss.h
  create mode 100644 drivers/media/video/omap4iss/iss_csi2.c
  create mode 100644 drivers/media/video/omap4iss/iss_csi2.h
  create mode 100644 drivers/media/video/omap4iss/iss_csiphy.c
  create mode 100644 drivers/media/video/omap4iss/iss_csiphy.h
  create mode 100644 drivers/media/video/omap4iss/iss_regs.h
  create mode 100644 drivers/media/video/omap4iss/iss_video.c
  create mode 100644 drivers/media/video/omap4iss/iss_video.h
  create mode 100644 drivers/media/video/ov5640.c
  create mode 100644 drivers/media/video/ov5650.c
  create mode 100644 include/media/ov5640.h
  create mode 100644 include/media/ov5650.h

 --
 1.7.7.4

--
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  

Re: [RFC][PATCH 2/2] v4l2: Add lv8093 lens driver

2011-09-18 Thread Aguirre, Sergio
Hi Mauro/Laurent,

On Sun, Sep 18, 2011 at 7:53 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi,

 On Sunday 18 September 2011 14:25:50 Mauro Carvalho Chehab wrote:
 Em 13-07-2010 20:40, Sergio Aguirre escreveu:
  This adds LV8093 Piezo Actuator Lens driver.
 
  This is currently found in tandem with IMX046 sensor.

 Due to patchwork.kernel.org long outage, I'm working on setting a new
 patchwork instance somewhere else. So, I'm importing the old patches and
 double-check if something were missed.

 In this proccess, I noticed that, for two times, a driver for lv8093 were
 proposed, one as part of the OMAPZOOM series of patches, back in Feb/2009,
 and a second submission, on this series.

 However, it seems that this were never applied, even not having any single
 comment on the last time you've submitted it, as a RFC.

 It seems that the omap3 maintainer lost those patches, or am I missing
 something?

 If you're talking about the OMAP3 ISP maintainer, indeed, I've never even
 noticed the patches :-)

This patches are so old, that I've forgotten completely about them :P

I'll actually need to dust off my old Zoom3 HW I have around to retest this. :)

And BTW, Dominic doesn't work at TI since last year, so I'm unlooping
his e-mail address.


 Review inlined.

Ok. Thanks.


  Signed-off-by: Sergio Aguirre saagui...@ti.com
  ---
 
   drivers/media/video/Kconfig       |    8 +
   drivers/media/video/Makefile      |    1 +
   drivers/media/video/lv8093.c      |  614 
   drivers/media/video/lv8093_regs.h |   76 +
   include/media/lv8093.h            |   40 +++
   include/media/v4l2-chip-ident.h   |    3 +
   6 files changed, 742 insertions(+), 0 deletions(-)
   create mode 100644 drivers/media/video/lv8093.c
   create mode 100644 drivers/media/video/lv8093_regs.h
   create mode 100644 include/media/lv8093.h
 
  diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
  index 10cd7b3..b62adce 100644
  --- a/drivers/media/video/Kconfig
  +++ b/drivers/media/video/Kconfig
  @@ -344,6 +344,14 @@ config VIDEO_IMX046
 
        IMX046 camera.  It is currently working with the TI OMAP3
        camera controller.
 
  +config VIDEO_LV8093
  +   tristate Piezo Actuator Lens driver for LV8093
  +   depends on I2C  VIDEO_V4L2
  +   ---help---
  +     This is a Video4Linux2 lens driver for the Sanyo LV8093.
  +     It is currently working with the TI OMAP3 camera controller
  +     and Sony IMX046 sensor.
  +

 You will need to implement the media controller API to work with the TI OMAP3
 ISP.

Yeah. I think I've implemented this driver when Media Controller
wasn't still upstreamed,
and under review still.


   config VIDEO_SAA7110
 
      tristate Philips SAA7110 video decoder
      depends on VIDEO_V4L2  I2C
 
  diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
  index 00341cb..50f528c 100644
  --- a/drivers/media/video/Makefile
  +++ b/drivers/media/video/Makefile
  @@ -39,6 +39,7 @@ obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o
 
   obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o
   obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o
   obj-$(CONFIG_VIDEO_IMX046) += imx046.o
 
  +obj-$(CONFIG_VIDEO_LV8093) += lv8093.o
 
   obj-$(CONFIG_VIDEO_SAA7110) += saa7110.o
   obj-$(CONFIG_VIDEO_SAA711X) += saa7115.o
   obj-$(CONFIG_VIDEO_SAA717X) += saa717x.o
 
  diff --git a/drivers/media/video/lv8093.c b/drivers/media/video/lv8093.c
  new file mode 100644
  index 000..b0b0fcf
  --- /dev/null
  +++ b/drivers/media/video/lv8093.c
  @@ -0,0 +1,614 @@
  +/*
  + * drivers/media/video/lv8093.c
  + *
  + * LV8093 Piezo Motor (LENS) driver
  + *
  + * Copyright (C) 2008-2009 Texas Instruments.
  + * Copyright (C) 2009 Hewlett-Packard.
  + *
  + * This package is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU General Public License version 2 as
  + * published by the Free Software Foundation.
  + *
  + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
  + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
  + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
  + */
  +
  +#include linux/mutex.h
  +#include linux/i2c.h
  +#include linux/delay.h
  +#include linux/platform_device.h
  +#include linux/cdev.h
  +#include linux/device.h
  +
  +#include media/lv8093.h
  +#include media/v4l2-chip-ident.h
  +#include media/v4l2-device.h
  +#include media/v4l2-subdev.h
  +
  +#include lv8093_regs.h
  +
  +static struct vcontrol {
  +   struct v4l2_queryctrl qc;
  +} video_control[] = {
  +   {
  +           {
  +           .id = V4L2_CID_FOCUS_RELATIVE,
  +           .type = V4L2_CTRL_TYPE_INTEGER,
  +           .name = Lens Relative Position,
  +           .minimum = 0,
  +           .maximum = 0,
  +           .step = LV8093_MAX_RELATIVE_STEP,
  +           .default_value = 0,
  +           }
  +   ,}
  +};
  +
  +static struct i2c_driver lv8093_i2c_driver;
  +
  +static struct 

Re: [PATCH 8/8] ARM: S5PV210: example of CMA private area for FIMC device on Goni board

2011-08-24 Thread Aguirre, Sergio
Hi Marek/Kyungmin,

On Fri, Aug 19, 2011 at 04:27:44PM +0200, Marek Szyprowski wrote:
 This patch is an example how device private CMA area can be activated.
 It creates one CMA region and assigns it to the first s5p-fimc device on
 Samsung Goni S5PC110 board.

 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/mach-s5pv210/mach-goni.c |4 
  1 files changed, 4 insertions(+), 0 deletions(-)
 diff --git a/arch/arm/mach-s5pv210/mach-goni.c 
 b/arch/arm/mach-s5pv210/mach-goni.c
 index 14578f5..f766c45 100644
 --- a/arch/arm/mach-s5pv210/mach-goni.c
 +++ b/arch/arm/mach-s5pv210/mach-goni.c
 @@ -26,6 +26,7 @@
  #include linux/input.h
  #include linux/gpio.h
  #include linux/interrupt.h
 +#include linux/dma-contiguous.h

  #include asm/mach/arch.h
  #include asm/mach/map.h
 @@ -857,6 +858,9 @@ static void __init goni_map_io(void)
  static void __init goni_reserve(void)
  {
   s5p_mfc_reserve_mem(0x4300, 8  20, 0x5100, 8  20);
 +
 + /* Create private 16MiB contiguous memory area for s5p-fimc.0 device */
 + dma_declare_contiguous(s5p_device_fimc0.dev, 16*SZ_1M, 0);

This is broken, since according to patch #0006, dma_declare_contiguous requires
a 4th param (limit) which you're not providing here.

Regards,
Sergio

  }

  static void __init goni_machine_init(void)
 --
 1.7.1.569.g6f426
--
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: [PATCH/RFC] V4L: add media bus configuration subdev operations

2011-06-06 Thread Aguirre, Sergio
Hi Guennadi,

Thanks for the patch.

On Mon, Jun 6, 2011 at 7:31 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
 Add media bus configuration types and two subdev operations to get
 supported mediabus configurations and to set a specific configuration.
 Subdevs can support several configurations, e.g., they can send video data
 on 1 or several lanes, can be configured to use a specific CSI-2 channel,
 in such cases subdevice drivers return bitmasks with all respective bits
 set. When a set-configuration operation is called, it has to specify a
 non-ambiguous configuration.

 Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 ---

 This change would allow a re-use of soc-camera and standard subdev
 drivers. It is a modified and extended version of

 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/29408

 therefore the original Sob. After this we only would have to switch to the
 control framework:) Please, comment.

 diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
 index 971c7fa..0983b7b 100644
 --- a/include/media/v4l2-mediabus.h
 +++ b/include/media/v4l2-mediabus.h
 @@ -13,6 +13,76 @@

  #include linux/v4l2-mediabus.h

 +/* Parallel flags */
 +/* Can the client run in master or in slave mode */
 +#define V4L2_MBUS_MASTER                       (1  0)
 +#define V4L2_MBUS_SLAVE                                (1  1)
 +/* Which signal polarities it supports */
 +#define V4L2_MBUS_HSYNC_ACTIVE_HIGH            (1  2)
 +#define V4L2_MBUS_HSYNC_ACTIVE_LOW             (1  3)
 +#define V4L2_MBUS_VSYNC_ACTIVE_HIGH            (1  4)
 +#define V4L2_MBUS_VSYNC_ACTIVE_LOW             (1  5)
 +#define V4L2_MBUS_PCLK_SAMPLE_RISING           (1  6)
 +#define V4L2_MBUS_PCLK_SAMPLE_FALLING          (1  7)
 +#define V4L2_MBUS_DATA_ACTIVE_HIGH             (1  8)
 +#define V4L2_MBUS_DATA_ACTIVE_LOW              (1  9)
 +/* Which datawidths are supported */
 +#define V4L2_MBUS_DATAWIDTH_4                  (1  10)
 +#define V4L2_MBUS_DATAWIDTH_8                  (1  11)
 +#define V4L2_MBUS_DATAWIDTH_9                  (1  12)
 +#define V4L2_MBUS_DATAWIDTH_10                 (1  13)
 +#define V4L2_MBUS_DATAWIDTH_15                 (1  14)
 +#define V4L2_MBUS_DATAWIDTH_16                 (1  15)
 +
 +#define V4L2_MBUS_DATAWIDTH_MASK       (V4L2_MBUS_DATAWIDTH_4 | 
 V4L2_MBUS_DATAWIDTH_8 | \
 +                                        V4L2_MBUS_DATAWIDTH_9 | 
 V4L2_MBUS_DATAWIDTH_10 | \
 +                                        V4L2_MBUS_DATAWIDTH_15 | 
 V4L2_MBUS_DATAWIDTH_16)
 +
 +/* Serial flags */
 +/* How many lanes the client can use */
 +#define V4L2_MBUS_CSI2_1_LANE                  (1  0)
 +#define V4L2_MBUS_CSI2_2_LANE                  (1  1)
 +#define V4L2_MBUS_CSI2_3_LANE                  (1  2)
 +#define V4L2_MBUS_CSI2_4_LANE                  (1  3)
 +/* On which channels it can send video data */
 +#define V4L2_MBUS_CSI2_CHANNEL_0                       (1  4)
 +#define V4L2_MBUS_CSI2_CHANNEL_1                       (1  5)
 +#define V4L2_MBUS_CSI2_CHANNEL_2                       (1  6)
 +#define V4L2_MBUS_CSI2_CHANNEL_3                       (1  7)
 +/* Does it support only continuous or also non-contimuous clock mode */

Typo: non-continuous

 +#define V4L2_MBUS_CSI2_CONTINUOUS_CLOCK                (1  8)

Doesn't having above bit disabled, imply a non-continuous clock already?

 +#define V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK     (1  9)

Regards,
Sergio

 +
 +#define V4L2_MBUS_CSI2_LANES           (V4L2_MBUS_CSI2_1_LANE | 
 V4L2_MBUS_CSI2_2_LANE | \
 +                                        V4L2_MBUS_CSI2_3_LANE | 
 V4L2_MBUS_CSI2_4_LANE)
 +#define V4L2_MBUS_CSI2_CHANNELS                (V4L2_MBUS_CSI2_CHANNEL_0 | 
 V4L2_MBUS_CSI2_CHANNEL_1 | \
 +                                        V4L2_MBUS_CSI2_CHANNEL_2 | 
 V4L2_MBUS_CSI2_CHANNEL_3)
 +
 +/**
 + * v4l2_mbus_type - media bus type
 + * @V4L2_MBUS_PARALLEL:        parallel interface with hsync and vsync
 + * @V4L2_MBUS_BT656:   parallel interface with embedded synchronisation
 + * @V4L2_MBUS_CSI2:    MIPI CSI-2 serial interface
 + */
 +enum v4l2_mbus_type {
 +       V4L2_MBUS_PARALLEL,
 +       V4L2_MBUS_BT656,
 +       V4L2_MBUS_CSI2,
 +};
 +
 +/**
 + * v4l2_mbus_config - media bus configuration
 + * @type:      interface type
 + * @flags:     configuration flags, depending on @type
 + * @clk:       output clock, the bridge driver can try to use 
 clk_set_parent()
 + *             to specify the master clock to the client
 + */
 +struct v4l2_mbus_config {
 +       enum v4l2_mbus_type type;
 +       unsigned long flags;
 +       struct clk *clk;
 +};
 +
  static inline void v4l2_fill_pix_format(struct v4l2_pix_format *pix_fmt,
                                const struct v4l2_mbus_framefmt *mbus_fmt)
  {
 diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
 index 1562c4f..6ea25f4 100644
 --- a/include/media/v4l2-subdev.h
 +++ 

Re: [ANNOUNCE] New OMAP4 V4L2 Camera Project started

2011-05-13 Thread Aguirre, Sergio
On Fri, May 13, 2011 at 6:01 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
 Aguirre, Sergio wrote:
 Hi all,

 Hi, Sergio!

Hi Sakari,


 Just to let you know that I've just officially registered for a new
 project in the Pandaboard.org portal for OMAP4 v4l2 camera support.

 You can find it here:

 http://omiio.org/content/omap4-v4l2-camera

 And also, you can find the actual Gitorious project with the code here:

 https://www.gitorious.org/omap4-v4l2-camera

 If anyone is interested in contributing for this project, please let
 me know, so I can add you as a contributor to the project.

 I'm very, very happy to see a project to start implementing V4L2 support
 for the OMAP 4 ISS!! Thanks, Sergio!

I'm pretty excited about it too :) Thanks.


 A few comments:


 - The driver is using videobuf. I wonder if the driver would benefit
 more from videobuf2.


Sure, that's definitely one of the first targets. I'll migrate to it.


 - As far as I understand, the OMAP 4 ISS is partially similar to the
 OMAP 3 one in design --- it has a hardware pipeline, that is. Fitting
 the bus receivers and the ISP under an Media controller graph looks
 relatively straightforward. The same might apply to SIMCOP, but then the
 question is: what kind of interface should the SIMCOP have?

That's a big question :) And I'm yet not sure on that. I'll certainly need to
think about it, and probably start planning for RFCs.

BTW, this driver is just implementing a super simple CSI2-A Rx - MEM
pipeline so far. I started with this because i wanted to avoid wasting my time
on developing somethign huge, and having to do heavy rework after reviews
take place.


 Being familiar with the history of the OMAP 3 ISP driver, I know this is
 not a small project. Still, starting to use the Media controller in an
 early phase would benefit the project in long run since the conversion
 can be avoided later.

Agreed.



 Which parts of the ISS require regular attention from the M3s? Is it the
 whole ISS or just the SIMCOP, for example?

In theory, the whole ISS, which includes SIMCOP, cna be driven from either
A9 or M3 cores.

Architecturally, it's better to keep the dedicated M3 cores for
driving ISS, and to
save some considerable cycles from A9. Problem is, we have to deal with IPC
communication channels, and that might make the driver much more complex
and requiring much more software layers to be in place for that.

The long term vision about this is that, it might be good ot see how easy is to
keep a Media Controller device, which sends the pipeline and subdevice
configuration
to M3 software, and just keep the Board specific and Usecases in A9 side.

Immediate problems are how to approach this with purely open source tools.
(As far as I know, it's so far only possible with TI proprietary compilers)

So, it might definitely take this discussion to a much more complex
level and more
complete analysis. Hopefully we can have a good discussion about the long term
future of this.

So far, I'm just starting with the simple stuff, ISS CSI2 Rx interface :)

Kiitos! Thanks for the interest.

Regards,
Sergio


 Kind regards,
 Sakari Ailus

 Ps. I have nothing against SoC camera, but when I look at the ISS
 overview diagram (section 8.1 in my TRM) I can't avoid thinking that
 this is exactly what the Media controller was created for. :-)

The main reason why it started as a soc_camera is because I started this
driver in a 2.6.35 android kernel, and refused to backport all the
Media Controller patches to it :)

But now being based in mainline, that's a different story. ;)


 --
 Sakari Ailus
 sakari.ai...@iki.fi

--
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


[ANNOUNCE] New OMAP4 V4L2 Camera Project started

2011-05-12 Thread Aguirre, Sergio
Hi all,

Just to let you know that I've just officially registered for a new
project in the Pandaboard.org portal for OMAP4 v4l2 camera support.

You can find it here:

http://omiio.org/content/omap4-v4l2-camera

And also, you can find the actual Gitorious project with the code here:

https://www.gitorious.org/omap4-v4l2-camera

If anyone is interested in contributing for this project, please let
me know, so I can add you as a contributor to the project.

Regards,
Sergio
--
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


[Query] Anyone here working with the mainline omap3isp driver?

2011-05-09 Thread Aguirre, Sergio
Hi Everyone,

I'll just like to know if there's someone working with the mainline
version of the omap3isp driver.

Ohad (in CC) has some omap3 iommu changes which might affect the
omap3isp driver.

I have been a bit away of the omap3 driver these days, so, if there's
someone else that can try some iommu changes on top, that'll be great.

Regards,
Sergio
--
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: [PATCH] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c

2011-04-12 Thread Aguirre, Sergio
On Mon, Apr 11, 2011 at 4:52 PM, Janusz Krzysztofik
jkrzy...@tis.icnet.pl wrote:
 Dnia poniedziałek 11 kwiecień 2011 o 22:05:35 Aguirre, Sergio
 napisał(a):

 Please find below a refreshed patch, which should be based on
 mainline commit:

 Hi,
 This version works for me, and fixes the regression.

Ok, Thanks for testing.

Guennadi,

It's up to you if you want to take your patch or mine. I guess I just wanted
to be more complete in my patch, but strictly speaking about a regression
fix (And based on what the current popular apps do), both do the job.

This was just my proposal :).

Regards,
Sergio


 Thanks,
 Janusz

 From f767059c12c755ebe79c4b74de17c23a257007c7 Mon Sep 17 00:00:00
 2001

 From: Sergio Aguirre saagui...@ti.com
 Date: Mon, 11 Apr 2011 11:14:33 -0500
 Subject: [PATCH] V4L: soc-camera: regression fix: calculate
 .sizeimage in soc_camera.c

 A recent patch has given individual soc-camera host drivers a
 possibility to calculate .sizeimage and .bytesperline pixel format
 fields internally, however, some drivers relied on the core
 calculating these values for them, following a default algorithm.
 This patch restores the default calculation for such drivers.

 Based on initial patch by Guennadi Liakhovetski, found here:

 http://www.spinics.net/lists/linux-media/msg31282.html

 Except that this covers try_fmt aswell.

 Signed-off-by: Sergio Aguirre saagui...@ti.com
 ---
  drivers/media/video/soc_camera.c |   48
 + 1 files changed, 42
 insertions(+), 6 deletions(-)

 diff --git a/drivers/media/video/soc_camera.c
 b/drivers/media/video/soc_camera.c index 4628448..dcc6623 100644
 --- a/drivers/media/video/soc_camera.c
 +++ b/drivers/media/video/soc_camera.c
 @@ -136,11 +136,50 @@ unsigned long
 soc_camera_apply_sensor_flags(struct soc_camera_link *icl,
  }
  EXPORT_SYMBOL(soc_camera_apply_sensor_flags);

 +#define pixfmtstr(x) (x)  0xff, ((x)  8)  0xff, ((x)  16) 
 0xff, \ +     ((x)  24)  0xff
 +
 +static int soc_camera_try_fmt(struct soc_camera_device *icd,
 +                           struct v4l2_format *f)
 +{
 +     struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
 +     struct v4l2_pix_format *pix = f-fmt.pix;
 +     int ret;
 +
 +     dev_dbg(icd-dev, TRY_FMT(%c%c%c%c, %ux%u)\n,
 +             pixfmtstr(pix-pixelformat), pix-width, pix-height);
 +
 +     pix-bytesperline = 0;
 +     pix-sizeimage = 0;
 +
 +     ret = ici-ops-try_fmt(icd, f);
 +     if (ret  0)
 +             return ret;
 +
 +     if (!pix-sizeimage) {
 +             if (!pix-bytesperline) {
 +                     const struct soc_camera_format_xlate *xlate;
 +
 +                     xlate = soc_camera_xlate_by_fourcc(icd, 
 pix-pixelformat);
 +                     if (!xlate)
 +                             return -EINVAL;
 +
 +                     ret = soc_mbus_bytes_per_line(pix-width,
 +                                                   xlate-host_fmt);
 +                     if (ret  0)
 +                             pix-bytesperline = ret;
 +             }
 +             if (pix-bytesperline)
 +                     pix-sizeimage = pix-bytesperline * pix-height;
 +     }
 +
 +     return 0;
 +}
 +
  static int soc_camera_try_fmt_vid_cap(struct file *file, void *priv,
                                     struct v4l2_format *f)
  {
       struct soc_camera_device *icd = file-private_data;
 -     struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);

       WARN_ON(priv != file-private_data);

 @@ -149,7 +188,7 @@ static int soc_camera_try_fmt_vid_cap(struct file
 *file, void *priv,
               return -EINVAL;

       /* limit format to hardware capabilities */
 -     return ici-ops-try_fmt(icd, f);
 +     return soc_camera_try_fmt(icd, f);
  }

  static int soc_camera_enum_input(struct file *file, void *priv,
 @@ -362,9 +401,6 @@ static void soc_camera_free_user_formats(struct
 soc_camera_device *icd)
       icd-user_formats = NULL;
  }

 -#define pixfmtstr(x) (x)  0xff, ((x)  8)  0xff, ((x)  16) 
 0xff, \ -     ((x)  24)  0xff
 -
  /* Called with .vb_lock held, or from the first open(2), see comment
 there */ static int soc_camera_set_fmt(struct soc_camera_device
 *icd, struct v4l2_format *f)
 @@ -377,7 +413,7 @@ static int soc_camera_set_fmt(struct
 soc_camera_device *icd, pixfmtstr(pix-pixelformat), pix-width,
 pix-height);

       /* We always call try_fmt() before set_fmt() or set_crop() */
 -     ret = ici-ops-try_fmt(icd, f);
 +     ret = soc_camera_try_fmt(icd, f);
       if (ret  0)
               return ret;

--
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: [PATCH] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c

2011-04-12 Thread Aguirre, Sergio
2011/4/12 Janusz Krzysztofik jkrzy...@tis.icnet.pl:
 Dnia wtorek 12 kwiecień 2011 o 17:39:35 Aguirre, Sergio napisał(a):
 On Mon, Apr 11, 2011 at 4:52 PM, Janusz Krzysztofik

 jkrzy...@tis.icnet.pl wrote:
  Dnia poniedziałek 11 kwiecień 2011 o 22:05:35 Aguirre, Sergio
 
  napisał(a):
  Please find below a refreshed patch, which should be based on
 
  mainline commit:
  Hi,
  This version works for me, and fixes the regression.

 Ok, Thanks for testing.

 I forgot to mention: the patch didn't apply cleanly, I had to unwrap a
 few lines manually, so you may want to resend it unwrapped.

Hmm,

I think that's a problem with my mail servers :/

Anyways, I'm attaching it now. Hopefully that's unwrapped.

Regards,
Sergio

 Thanks,
 Janusz

From f767059c12c755ebe79c4b74de17c23a257007c7 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Mon, 11 Apr 2011 11:14:33 -0500
Subject: [PATCH] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c

A recent patch has given individual soc-camera host drivers a possibility
to calculate .sizeimage and .bytesperline pixel format fields internally,
however, some drivers relied on the core calculating these values for
them, following a default algorithm. This patch restores the default
calculation for such drivers.

Based on initial patch by Guennadi Liakhovetski, found here:

http://www.spinics.net/lists/linux-media/msg31282.html

Except that this covers try_fmt aswell.

Signed-off-by: Sergio Aguirre saagui...@ti.com
---
 drivers/media/video/soc_camera.c |   48 +
 1 files changed, 42 insertions(+), 6 deletions(-)

diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 4628448..dcc6623 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -136,11 +136,50 @@ unsigned long soc_camera_apply_sensor_flags(struct soc_camera_link *icl,
 }
 EXPORT_SYMBOL(soc_camera_apply_sensor_flags);
 
+#define pixfmtstr(x) (x)  0xff, ((x)  8)  0xff, ((x)  16)  0xff, \
+	((x)  24)  0xff
+
+static int soc_camera_try_fmt(struct soc_camera_device *icd,
+			  struct v4l2_format *f)
+{
+	struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+	struct v4l2_pix_format *pix = f-fmt.pix;
+	int ret;
+
+	dev_dbg(icd-dev, TRY_FMT(%c%c%c%c, %ux%u)\n,
+		pixfmtstr(pix-pixelformat), pix-width, pix-height);
+
+	pix-bytesperline = 0;
+	pix-sizeimage = 0;
+
+	ret = ici-ops-try_fmt(icd, f);
+	if (ret  0)
+		return ret;
+
+	if (!pix-sizeimage) {
+		if (!pix-bytesperline) {
+			const struct soc_camera_format_xlate *xlate;
+
+			xlate = soc_camera_xlate_by_fourcc(icd, pix-pixelformat);
+			if (!xlate)
+return -EINVAL;
+
+			ret = soc_mbus_bytes_per_line(pix-width,
+		  xlate-host_fmt);
+			if (ret  0)
+pix-bytesperline = ret;
+		}
+		if (pix-bytesperline)
+			pix-sizeimage = pix-bytesperline * pix-height;
+	}
+
+	return 0;
+}
+
 static int soc_camera_try_fmt_vid_cap(struct file *file, void *priv,
   struct v4l2_format *f)
 {
 	struct soc_camera_device *icd = file-private_data;
-	struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
 
 	WARN_ON(priv != file-private_data);
 
@@ -149,7 +188,7 @@ static int soc_camera_try_fmt_vid_cap(struct file *file, void *priv,
 		return -EINVAL;
 
 	/* limit format to hardware capabilities */
-	return ici-ops-try_fmt(icd, f);
+	return soc_camera_try_fmt(icd, f);
 }
 
 static int soc_camera_enum_input(struct file *file, void *priv,
@@ -362,9 +401,6 @@ static void soc_camera_free_user_formats(struct soc_camera_device *icd)
 	icd-user_formats = NULL;
 }
 
-#define pixfmtstr(x) (x)  0xff, ((x)  8)  0xff, ((x)  16)  0xff, \
-	((x)  24)  0xff
-
 /* Called with .vb_lock held, or from the first open(2), see comment there */
 static int soc_camera_set_fmt(struct soc_camera_device *icd,
 			  struct v4l2_format *f)
@@ -377,7 +413,7 @@ static int soc_camera_set_fmt(struct soc_camera_device *icd,
 		pixfmtstr(pix-pixelformat), pix-width, pix-height);
 
 	/* We always call try_fmt() before set_fmt() or set_crop() */
-	ret = ici-ops-try_fmt(icd, f);
+	ret = soc_camera_try_fmt(icd, f);
 	if (ret  0)
 		return ret;
 
-- 
1.7.0.4



[soc_camera] Dynamic crop window change while streaming (Zoom case)?

2011-04-12 Thread Aguirre, Sergio
Hi Guennadi,

I was wondering what's the stand on allowing soc_camera host drivers to have
internal scalers...

It looks possible, but however I see one important blocker for being able to
change window rectangle while streaming (for example, when attempting to do
zoom in/out during streaming). See here:

in soc_camera.c::soc_camera_s_crop()

...
/* If get_crop fails, we'll let host and / or client drivers decide */
ret = ici-ops-get_crop(icd, current_crop);

/* Prohibit window size change with initialised buffers */
if (ret  0) {
dev_err(icd-dev,
S_CROP denied: getting current crop failed\n);
} else if (icd-vb_vidq.bufs[0] 
   (a-c.width != current_crop.c.width ||
a-c.height != current_crop.c.height)) {
dev_err(icd-dev,
S_CROP denied: queue initialised and sizes differ\n);
ret = -EBUSY;
} else {
ret = ici-ops-set_crop(icd, a);
}
...

Now, I don't want to move just yet to a Media Controller implementation in my
omap4 camera driver, since I don't intend yet to exploit the full HW, which
is easly 2x more complicated than omap3. But I want to start with a simplistic
driver which Pandaboard community can take (which don't need any advanced
features, just being able to receive frames.) and i just want to know how
complicated is to just offer the scaler functionality still.

Regards,
Sergio
--
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: [PATCH] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c

2011-04-11 Thread Aguirre, Sergio
Hi Guennadi,

On Mon, Apr 11, 2011 at 8:23 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:

 On Mon, 11 Apr 2011, Aguirre, Sergio wrote:

  Hi Guennadi,
 
  On Mon, Apr 11, 2011 at 3:58 AM, Guennadi Liakhovetski 
  g.liakhovet...@gmx.de wrote:
 
   A recent patch has given individual soc-camera host drivers a possibility
   to calculate .sizeimage and .bytesperline pixel format fields internally,
   however, some drivers relied on the core calculating these values for
   them, following a default algorithm. This patch restores the default
   calculation for such drivers.
  
   Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
   ---
   diff --git a/drivers/media/video/soc_camera.c
   b/drivers/media/video/soc_camera.c
   index 4628448..0918c48 100644
   --- a/drivers/media/video/soc_camera.c
   +++ b/drivers/media/video/soc_camera.c
   @@ -376,6 +376,9 @@ static int soc_camera_set_fmt(struct soc_camera_device
   *icd,
          dev_dbg(icd-dev, S_FMT(%c%c%c%c, %ux%u)\n,
                  pixfmtstr(pix-pixelformat), pix-width, pix-height);
  
   +       pix-bytesperline = 0;
   +       pix-sizeimage = 0;
   +
          /* We always call try_fmt() before set_fmt() or set_crop() */
          ret = ici-ops-try_fmt(icd, f);
          if (ret  0)
   @@ -391,6 +394,17 @@ static int soc_camera_set_fmt(struct 
   soc_camera_device
   *icd,
                  return -EINVAL;
          }
  
   +       if (!pix-sizeimage) {
   +               if (!pix-bytesperline) {
   +                       ret = soc_mbus_bytes_per_line(pix-width,
   +
   icd-current_fmt-host_fmt);
   +                       if (ret  0)
   +                               pix-bytesperline = ret;
   +               }
   +               if (pix-bytesperline)
   +                       pix-sizeimage = pix-bytesperline * pix-height;
   +       }
   +
  
 
  Shouldn't all this be better done in try_fmt?

 Not _better_. We might choose to additionally do it for try_fmt too. But

 1. we didn't do it before, applications don't seem to care.
 2. you cannot store / reuse those .sizeimage  .bytesperline values - this
 is just a try
 3. it would be a bit difficult to realise - we need a struct
 soc_mbus_pixelfmt to call soc_mbus_bytes_per_line(), which we don't have,
 so, we'd need to obtain it using soc_camera_xlate_by_fourcc().

 This all would work, but in any case it would be an enhancement, but not a
 regression fix.

Ok. And how about the attached patch? Would that work?

Regards,
Sergio


 Thanks
 Guennadi
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/
From 5442074c7760429c06f62917503c1d8a2f79cd21 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Mon, 11 Apr 2011 11:14:33 -0500
Subject: [PATCH] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c

A recent patch has given individual soc-camera host drivers a possibility
to calculate .sizeimage and .bytesperline pixel format fields internally,
however, some drivers relied on the core calculating these values for
them, following a default algorithm. This patch restores the default
calculation for such drivers.

Based on initial patch by Guennadi Liakhovetski, found here:

http://www.spinics.net/lists/linux-media/msg31282.html

Except that this covers try_fmt aswell.

Signed-off-by: Sergio Aguirre saagui...@ti.com
---
 drivers/media/video/soc_camera.c |   41 -
 1 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 4628448..875842a 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -136,6 +136,43 @@ unsigned long soc_camera_apply_sensor_flags(struct soc_camera_link *icl,
 }
 EXPORT_SYMBOL(soc_camera_apply_sensor_flags);
 
+static int soc_camera_try_fmt(struct soc_camera_device *icd,
+			  struct v4l2_format *f)
+{
+	struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+	struct v4l2_pix_format *pix = f-fmt.pix;
+	int ret;
+
+	dev_dbg(icd-dev, TRY_FMT(%c%c%c%c, %ux%u)\n,
+		pixfmtstr(pix-pixelformat), pix-width, pix-height);
+
+	pix-bytesperline = 0;
+	pix-sizeimage = 0;
+
+	ret = ici-ops-try_fmt(icd, f);
+	if (ret  0)
+		return ret;
+
+	if (!pix-sizeimage) {
+		if (!pix-bytesperline) {
+			const struct soc_camera_format_xlate *xlate;
+
+			xlate = soc_camera_xlate_by_fourcc(icd, pix-pixelformat);
+			if (!xlate)
+return -EINVAL;
+
+			ret = soc_mbus_bytes_per_line(pix-width,
+		  xlate-host_fmt);
+			if (ret  0)
+pix-bytesperline = ret;
+		}
+		if (pix-bytesperline)
+			pix-sizeimage = pix-bytesperline * pix-height;
+	}
+
+	return 0;
+}
+
 static int soc_camera_try_fmt_vid_cap(struct file *file, void *priv,
   struct v4l2_format *f)
 {
@@ -149,7 +186,7 @@ static int soc_camera_try_fmt_vid_cap(struct file *file, void *priv,
 		return -EINVAL;
 
 	/* limit format to hardware capabilities */
-	return ici

Re: [PATCH] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c

2011-04-11 Thread Aguirre, Sergio
On Mon, Apr 11, 2011 at 11:58 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
 On Mon, 11 Apr 2011, Aguirre, Sergio wrote:

 Hi Guennadi,

 On Mon, Apr 11, 2011 at 8:23 AM, Guennadi Liakhovetski
 g.liakhovet...@gmx.de wrote:
 
  On Mon, 11 Apr 2011, Aguirre, Sergio wrote:
 
   Hi Guennadi,
  
   On Mon, Apr 11, 2011 at 3:58 AM, Guennadi Liakhovetski 
   g.liakhovet...@gmx.de wrote:
  
A recent patch has given individual soc-camera host drivers a 
possibility
to calculate .sizeimage and .bytesperline pixel format fields 
internally,
however, some drivers relied on the core calculating these values for
them, following a default algorithm. This patch restores the default
calculation for such drivers.
   
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c
index 4628448..0918c48 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -376,6 +376,9 @@ static int soc_camera_set_fmt(struct 
soc_camera_device
*icd,
       dev_dbg(icd-dev, S_FMT(%c%c%c%c, %ux%u)\n,
               pixfmtstr(pix-pixelformat), pix-width, pix-height);
   
+       pix-bytesperline = 0;
+       pix-sizeimage = 0;
+
       /* We always call try_fmt() before set_fmt() or set_crop() */
       ret = ici-ops-try_fmt(icd, f);
       if (ret  0)
@@ -391,6 +394,17 @@ static int soc_camera_set_fmt(struct 
soc_camera_device
*icd,
               return -EINVAL;
       }
   
+       if (!pix-sizeimage) {
+               if (!pix-bytesperline) {
+                       ret = soc_mbus_bytes_per_line(pix-width,
+
icd-current_fmt-host_fmt);
+                       if (ret  0)
+                               pix-bytesperline = ret;
+               }
+               if (pix-bytesperline)
+                       pix-sizeimage = pix-bytesperline * 
pix-height;
+       }
+
   
  
   Shouldn't all this be better done in try_fmt?
 
  Not _better_. We might choose to additionally do it for try_fmt too. But
 
  1. we didn't do it before, applications don't seem to care.
  2. you cannot store / reuse those .sizeimage  .bytesperline values - this
  is just a try
  3. it would be a bit difficult to realise - we need a struct
  soc_mbus_pixelfmt to call soc_mbus_bytes_per_line(), which we don't have,
  so, we'd need to obtain it using soc_camera_xlate_by_fourcc().
 
  This all would work, but in any case it would be an enhancement, but not a
  regression fix.

 Ok. And how about the attached patch? Would that work?

 Please, post patches inline.

Ok, sorry.


 Yes, I think, ot would work too, only the call to
 soc_camera_xlate_by_fourcc() in the S_FMT case is superfluous, after
 ici-ops-set_fmt() we already have it in icd-current_fmt-host_fmt.

Well, the difference is that, after my patch, this is called after
ici-ops-try_fmt, so
icd-current_fmt-host_fmt doesn't match the intended format to try, as it's not
stored as a current_fmt.

Unless i'm getting confused with something...

Regards,
Sergio

 Otherwise - yes, we could do it this way too. Janusz, could you test,
 please?

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

--
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: [PATCH] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c

2011-04-11 Thread Aguirre, Sergio
On Mon, Apr 11, 2011 at 1:40 PM, Janusz Krzysztofik
jkrzy...@tis.icnet.pl wrote:
 Dnia poniedziałek 11 kwiecień 2011 o 18:58:51 Guennadi Liakhovetski 
 napisał(a):
 On Mon, 11 Apr 2011, Aguirre, Sergio wrote:
 
  Ok. And how about the attached patch? Would that work?

 Yes, I think, ot would work too, only the call to
 soc_camera_xlate_by_fourcc() in the S_FMT case is superfluous, after
 ici-ops-set_fmt() we already have it in icd-current_fmt-host_fmt.
 Otherwise - yes, we could do it this way too. Janusz, could you test,
 please?

 Looks like not based on the current mainline (-rc2) tree:

  CHECK   drivers/media/video/soc_camera.c
 drivers/media/video/soc_camera.c:146:9: error: undefined identifier 
 'pixfmtstr'
  CC      drivers/media/video/soc_camera.o
 drivers/media/video/soc_camera.c: In function 'soc_camera_try_fmt':
 drivers/media/video/soc_camera.c:146: error: implicit declaration of function 
 'pixfmtstr'
 drivers/media/video/soc_camera.c:146: warning: too few arguments for format
 drivers/media/video/soc_camera.c: In function 'soc_camera_try_fmt_vid_cap':
 drivers/media/video/soc_camera.c:180: warning: unused variable 'ici'


Oops, my bad.

Please find below a refreshed patch, which should be based on mainline commit:

b42282e pci: fix PCI bus allocation alignment handling




 Thanks,
 Janusz


From f767059c12c755ebe79c4b74de17c23a257007c7 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Mon, 11 Apr 2011 11:14:33 -0500
Subject: [PATCH] V4L: soc-camera: regression fix: calculate .sizeimage
in soc_camera.c

A recent patch has given individual soc-camera host drivers a possibility
to calculate .sizeimage and .bytesperline pixel format fields internally,
however, some drivers relied on the core calculating these values for
them, following a default algorithm. This patch restores the default
calculation for such drivers.

Based on initial patch by Guennadi Liakhovetski, found here:

http://www.spinics.net/lists/linux-media/msg31282.html

Except that this covers try_fmt aswell.

Signed-off-by: Sergio Aguirre saagui...@ti.com
---
 drivers/media/video/soc_camera.c |   48 +
 1 files changed, 42 insertions(+), 6 deletions(-)

diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 4628448..dcc6623 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -136,11 +136,50 @@ unsigned long
soc_camera_apply_sensor_flags(struct soc_camera_link *icl,
 }
 EXPORT_SYMBOL(soc_camera_apply_sensor_flags);

+#define pixfmtstr(x) (x)  0xff, ((x)  8)  0xff, ((x)  16)  0xff, \
+   ((x)  24)  0xff
+
+static int soc_camera_try_fmt(struct soc_camera_device *icd,
+ struct v4l2_format *f)
+{
+   struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+   struct v4l2_pix_format *pix = f-fmt.pix;
+   int ret;
+
+   dev_dbg(icd-dev, TRY_FMT(%c%c%c%c, %ux%u)\n,
+   pixfmtstr(pix-pixelformat), pix-width, pix-height);
+
+   pix-bytesperline = 0;
+   pix-sizeimage = 0;
+
+   ret = ici-ops-try_fmt(icd, f);
+   if (ret  0)
+   return ret;
+
+   if (!pix-sizeimage) {
+   if (!pix-bytesperline) {
+   const struct soc_camera_format_xlate *xlate;
+
+   xlate = soc_camera_xlate_by_fourcc(icd, 
pix-pixelformat);
+   if (!xlate)
+   return -EINVAL;
+
+   ret = soc_mbus_bytes_per_line(pix-width,
+ xlate-host_fmt);
+   if (ret  0)
+   pix-bytesperline = ret;
+   }
+   if (pix-bytesperline)
+   pix-sizeimage = pix-bytesperline * pix-height;
+   }
+
+   return 0;
+}
+
 static int soc_camera_try_fmt_vid_cap(struct file *file, void *priv,
  struct v4l2_format *f)
 {
struct soc_camera_device *icd = file-private_data;
-   struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);

WARN_ON(priv != file-private_data);

@@ -149,7 +188,7 @@ static int soc_camera_try_fmt_vid_cap(struct file
*file, void *priv,
return -EINVAL;

/* limit format to hardware capabilities */
-   return ici-ops-try_fmt(icd, f);
+   return soc_camera_try_fmt(icd, f);
 }

 static int soc_camera_enum_input(struct file *file, void *priv,
@@ -362,9 +401,6 @@ static void soc_camera_free_user_formats(struct
soc_camera_device *icd)
icd-user_formats = NULL;
 }

-#define pixfmtstr(x) (x)  0xff, ((x)  8)  0xff, ((x)  16)  0xff, \
-   ((x)  24)  0xff
-
 /* Called with .vb_lock held, or from the first open(2), see comment there */
 static int soc_camera_set_fmt(struct soc_camera_device *icd,
  struct v4l2_format *f)
@@ -377,7 +413,7 @@ static int soc_camera_set_fmt(struct

RE: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms

2011-02-23 Thread Aguirre, Sergio


 -Original Message-
 From: Hans Verkuil [mailto:hansv...@cisco.com]
 Sent: Wednesday, February 23, 2011 3:32 AM
 To: Hans Verkuil
 Cc: Sylwester Nawrocki; Guennadi Liakhovetski; Stan; linux-
 me...@vger.kernel.org; Laurent Pinchart; Aguirre, Sergio
 Subject: Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms
 
 On Wednesday, February 23, 2011 09:10:42 Hans Verkuil wrote:
  Unfortunately, if a subdev is set to 'sample at rising edge', then that
 does
  not necessarily mean that the host should sample at the same edge.
 Depending
  on the clock line routing and the integrity of the clock signal the host
 may
  actually have to sample on the other edge. And yes, I've seen this.
 
 It might be useful to give some background information regarding the
 sampling
 edge problems.
 
 There are two main reasons why the sampling edge can be hardware
 dependent.
 The first is if the data lines go through an amplifier or something
 similar
 that will slightly delay the data lines compared to the clock signal. This
 can
 shift the edge at which you have to sample.
 
 Actually, this may even be dependent on the clock frequency. I have not
 seen
 that in real life yet, but it might happen. This will complicate things
 even
 more since in that case you need to make a callback function in the board
 code
 that determines the sampling edge based on the clock frequency. I think we
 can
 ignore that for now, but we do need to keep it in mind.
 
 The other is the waveform of the clock. For relatively low frequencies
 this
 will resemble a symmetrical square wave. But for higher frequencies this
 more
 resembles the bottom waveform in this picture:
 
 http://myweb.msoe.edu/williamstm/Images/Divider2.jpg
 
 This is asymmetric so depending on the slopes the sampling edge can make
 quite
 a difference.
 
 The higher the clock frequency, the more asymmetric the waveform will
 look.

I think this a very specific HW problem (Low slew rate), and it's something
That should be fixed in HW, or avoided in SW after proper experimentation is
done.

One example on how to fix this is described in this document:

http://www.actel.com/documents/SchmittTrigger_AN.pdf

Regards,
Sergio

 
 Regards,
 
   Hans
--
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: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms

2011-02-23 Thread Aguirre, Sergio
Hi,

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Wednesday, February 23, 2011 10:15 AM
 To: Hans Verkuil
 Cc: Aguirre, Sergio; Guennadi Liakhovetski; Hans Verkuil; Sylwester
 Nawrocki; Stan; linux-media@vger.kernel.org
 Subject: Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms
 
 On Wednesday 23 February 2011 17:02:57 Hans Verkuil wrote:
  On Wednesday, February 23, 2011 16:30:42 Laurent Pinchart wrote:
   On Wednesday 23 February 2011 15:06:49 Aguirre, Sergio wrote:
snip
   
  The only static data I am concerned about are those that affect
  signal integrity.
 
  After thinking carefully about this I realized that there is
 really
  only one setting that is relevant to that: the sampling edge.
 The
  polarities do not matter in this.
   
I respectfully disagree.
  
   So do I. Sampling edge is related to polarities, so you need to take
 both
   into account.
 
  When you switch polarity for data/field/hsync/vsync signals on a simple
 bus
  you just invert whether a 1 bit is output as high or low voltage. So you
  just change the meaning of the bit. This does not matter for signal
  integrity, since you obviously have to be able to sample both low and
 high
  voltages. It is *when* you sample that can have a major effect.
 
 When you switch the polarity you will likely have to sample on the
 opposite
 edge. If, for signal integrity reasons, you can only sample on a given
 edge,
 you will want to use a fixed polarity and not negotiate it.

I guess this should be reason enough to decide this in platform data in the
board file.

 
 Given the very small number of parameters that are negotiated by soc-
 camera at
 the moment, I'm very much in favour of hardcoding all of them in platform
 data
 and just adding a g_interface_parms subdev operation.

I'll second that.

Negotiating all this adds unnecessary complexity, and just makes the code
More prone to errors, and even probably causing hardware damage due to
misconfiguration. It's better to keep this static and make the board config
fully conscious of it.

Regards,
Sergio

 
  This might be different for differential clocks. I have no experience
 with
  this, so I can't say anything sensible about that.
 
 --
 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: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms

2011-02-23 Thread Aguirre, Sergio
Hi Guennadi,

 -Original Message-
 From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
 Sent: Wednesday, February 23, 2011 10:46 AM
 To: Aguirre, Sergio
 Cc: Laurent Pinchart; Hans Verkuil; Sylwester Nawrocki; Stan; linux-
 me...@vger.kernel.org
 Subject: RE: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms
 
 On Wed, 23 Feb 2011, Aguirre, Sergio wrote:
 
  Hi,
 
   -Original Message-
   From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
   Sent: Wednesday, February 23, 2011 10:15 AM
   To: Hans Verkuil
   Cc: Aguirre, Sergio; Guennadi Liakhovetski; Hans Verkuil; Sylwester
   Nawrocki; Stan; linux-media@vger.kernel.org
   Subject: Re: [RFC/PATCH 0/1] New subdev sensor operation
 g_interface_parms
  
   On Wednesday 23 February 2011 17:02:57 Hans Verkuil wrote:
On Wednesday, February 23, 2011 16:30:42 Laurent Pinchart wrote:
 On Wednesday 23 February 2011 15:06:49 Aguirre, Sergio wrote:
  snip
 
The only static data I am concerned about are those that
 affect
signal integrity.
   
After thinking carefully about this I realized that there is
   really
only one setting that is relevant to that: the sampling
 edge.
   The
polarities do not matter in this.
 
  I respectfully disagree.

 So do I. Sampling edge is related to polarities, so you need to
 take
   both
 into account.
   
When you switch polarity for data/field/hsync/vsync signals on a
 simple
   bus
you just invert whether a 1 bit is output as high or low voltage. So
 you
just change the meaning of the bit. This does not matter for signal
integrity, since you obviously have to be able to sample both low
 and
   high
voltages. It is *when* you sample that can have a major effect.
  
   When you switch the polarity you will likely have to sample on the
   opposite
   edge. If, for signal integrity reasons, you can only sample on a given
   edge,
   you will want to use a fixed polarity and not negotiate it.
 
  I guess this should be reason enough to decide this in platform data in
 the
  board file.
 
  
   Given the very small number of parameters that are negotiated by soc-
   camera at
   the moment, I'm very much in favour of hardcoding all of them in
 platform
   data
   and just adding a g_interface_parms subdev operation.
 
  I'll second that.
 
  Negotiating all this adds unnecessary complexity, and just makes the
 code
  More prone to errors, and even probably causing hardware damage due to
  misconfiguration. It's better to keep this static and make the board
 config
  fully conscious of it.
 
 Sorry, I accept different opinions, and in the end only one of the two
 possibilities will be implemented, and either way it'll all work in the
 end, but, I don't buy either of these arguments.

 Complexity - the code is
 already there, it is working, it is simple, it has not broken since it has
 been implemented. I had it hard-coded in the beginning and I went over to
 negotiation and never regretted it.

First of all, it seems that this discussion is heavily parallel i/f
oriented, and soc_camera focused, and it's just not like that.

Now, _just_ for soc_camera framework, yeah... it works and it's there, but
still not providing a solution for other v4l2_subdev users (like Media
Controller).

Complexity comes only when trying to make this truly generic, and avoid
fragmentation of solutions (1 for soc, 1 for MC), plus adding support for
serial (MIPI) interfaces

Now, also, the patch originally proposed by Stan doesn't actually deal with
putting polarities as part of the interface parameters, which is something
you're currently negotiating in soc_camera framework, again, just for
parallel interfaces.

Now, just for the sake of clarifying my understanding, I guess what you're
saying is to make sensor driver expose all possible polarities and physical
details configurable, and make the platform data limit the actual options due 
to the physical layout.

For example, if in my board A, I have:

- OV5640 sensor driver, which supports both Parallel and CSI2
Interfaces (with up to 2 datalanes)
- Rx subdev (or host) driver(s) which support Parallel, CSI2-A and
CSI2-B interfaces (with 2 and 1 datalanes respectively).

I should specify in my boardfile integration details, such as the
sensor is actually wired to the CSI2-B I/f, so make the sensor
negotiate with the other side of the bus and enable CSI2 i/f with
given details, like just use 1 datalane, and match datalane
position/polarity.

Am I understanding right?

 
 Hardware damage - if this were the case, I'd probably be surrounded only
 by bricks. How configuring a wrong hsync polarity can damage your
 hardware?

Ok, I'll regret my statement on this one. I guess I was a bit too dramatic
to point out consequences of HW mismatches. Nevermind this.

Regards,
Sergio

 
 Thanks
 Guennadi
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance

RE: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms

2011-02-22 Thread Aguirre, Sergio
Hi,

 -Original Message-
 From: Hans Verkuil [mailto:hansv...@cisco.com]
 Sent: Tuesday, February 22, 2011 7:33 AM
 To: Guennadi Liakhovetski
 Cc: Stanimir Varbanov; linux-media@vger.kernel.org;
 laurent.pinch...@ideasonboard.com; Aguirre, Sergio
 Subject: Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms
 
 On Tuesday, February 22, 2011 12:40:32 Guennadi Liakhovetski wrote:
  On Tue, 22 Feb 2011, Stanimir Varbanov wrote:
 
   This RFC patch adds a new subdev sensor operation named
 g_interface_parms.
   It is planned as a not mandatory operation and it is driver's
 developer
   decision to use it or not.
  
   Please share your opinions and ideas.
 
 Stanimir, thanks for the RFC. I think it is time that we create a good
 solution for this. This is currently the last remaining issue preventing
 soc-
 camera subdevs from being used generally. (Control handling is also still
 special, but this is being worked on.)
 
  Yes, I like the idea in principle (/me pulling his bullet-proof vest
 on),
 
 :-)
 
  as some of you might guess, because I feel it's going away from the
 idea,
  that I've been hard pressed to accept of hard-coding the media-bus
  configuration and in the direction of direct communication of
  bus-parameters between the (sub-)devices, e.g., a camera host and a
 camera
  device in soc-camera terminology.
 
  But before reviewing the patch as such, I'd like to discuss the
 strategy,
  that we want to pursue here - what exactly do we want to hard-code and
  what we want to configure dynamically? As explained before, my
 preference
  would be to only specify the absolute minimum in the platform data,
 i.e.,
  parameters that either are ambiguous or special for this platform. So,
  once again, my approach to configure interface parameters like signal
  polarities and edge sensitivity is:
 
  1. if at least one side has a fixed value of the specific parameter,
  usually no need to specify it in platform data. Example: sensor only
  supports HSYNC active high, host supports both, normally high should
 be
  selected.
 
  2. as above, but there's an inverter on the board in the signal path.
 The
  invert parameter must be specified in the platform data and the host
  will configure itself to low and send high confirmed to the sensor.
 
  3. both are configurable. In this case the platform data has to specify,
  which polarity shall be used.
 
  This is simple, it is implemented, it has worked that way with no
 problem
  for several years now.
 
  The configuration procedure in this case looks like:
 
  1. host requests supported interface configurations from the client
  (sensor)
 
  2. host matches returned parameters against platform data and its own
  capabilities
 
  3. if no suitable configuration possible - error out
 
  4. the single possible configuration is identified and sent to the
 sensor
  back for its configuration
 
  This way we need one more method: s_interface_parms.
 
  Shortly talking to Laurent earlier today privately, he mentioned, that
 one
  of the reasons for this move is to support dynamic bus reconfiguration,
  e.g., the number of used CSI lanes. The same is useful for parallel
  interfaces. E.g., I had to hack the omap3spi driver to capture only 8
  (parallel) data lanes from the sensor, connected with all its 10 lanes
 to
  get a format, easily supported by user-space applications. Ideally you
  don't want to change anything in the code for this. If the user is
  requesting the 10-bit format, all 10 lanes are used, if only 8 - the
  interface is reconfigured accordingly.
 
 I have no problems with dynamic bus reconfiguration as such. So if the
 host
 driver wants to do lane reconfiguration, then that's fine by me.
 
 When it comes to signal integrity (polarity, rising/falling edge), then I
 remain convinced that this should be set via platform data. This is not
 something that should be negotiated since this depends not only on the
 sensor
 and host devices, but also on the routing of the lines between them on the
 actual board, how much noise there is on those lines, the quality of the
 clock
 signal, etc. Not really an issue with PAL/NTSC type signals, but when you
 get
 to 1080p60 and up, then such things become much more important.
 
 So these settings should not be negotiated, but set explicitly.
 
 It actually doesn't have to be done through platform data (although that
 makes
 the most sense), as long as it is explicitly set based on board-specific
 data.

My 2 cents here is that I think this consists in 2 parts, and should be
divided properly.

1. You know required # of lanes  clockspeed after you had set the format.
For example:

- VGA @ 30fps
  DDR Clk: 330 MHz
  Number of Datalanes: 1

- VGA @ 60fps
  DDR Clk: 330 MHz
  Number of Datalanes: 2

- 12MPix @ 10fps
  DDR Clk: 480 MHz
  Number of Datalanes: 2

This usually is something you know from the sensor config selected based
on your params.

So, I think this is something that the host

[Query] Soc_camera: Passing MIPI bus physical link details

2011-02-16 Thread Aguirre, Sergio
Hi Guennadi,

I have been working internally in a private 2.6.35.7 kernel with the TI OMAP4
platform, and as I have a very simple camera support driver (It just enables a
CSI2 Rx Interface), i decided to go for a soc-camera host implementation.

Now, I see that there is a set_bus_param callback function for host drivers,
which if i understand correctly, it tries to negotiate the bus parameters
between the host and the client.

But what i notice is that this seems to be mostly oriented towards a parallel
interface, as most of the things won't make much sense in MIPI CSI2 spec
(HSYNC_ACTIVE_HIGH, DATAWIDTH_x, etc.)

I was wondering what's the best way to be able to tell to the host driver
MIPI specific details such as, how many datalanes the interface is using, and
the MIPI Clk speed in which the sensor will be transmitting the data.

Does it make sense to expand this inside the [query/set]_bus_param APIs? or
Will it be better to implement a new v4l2_subdev_sensor_ops entry, something
like g_mipi_params?

Regards,
Sergio
--
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: [Query][videobuf-dma-sg] Pages in Highmem handling

2011-01-07 Thread Aguirre, Sergio
Hi Mauro,

 -Original Message-
 From: Mauro Carvalho Chehab [mailto:mche...@redhat.com]
 Sent: Monday, December 20, 2010 5:23 AM
 To: Aguirre, Sergio
 Cc: linux-media@vger.kernel.org; Warren, Christina; Boateng, Akwasi;
 Russell King
 Subject: Re: [Query][videobuf-dma-sg] Pages in Highmem handling
 
 Hi Sergio,
 
 Em 27-08-2010 11:57, Aguirre, Sergio escreveu:
  Hi,
 
  I see that in current videobuf library, for DMA SG code, these functions
 fail when
  Detecting a page in Highmem region:
 
  - videobuf_pages_to_sg
  - videobuf_vmalloc_to_sg
 
  Now, what's the real reason to not allow handling of Highmem pages?
  Is it an assumption that _always_ HighMem is not reachable by DMA?
 
  I guess my point is, OMAP platform (and maybe other platforms) can
 handle
  Highmem pages without any problem. I commented these validations:
 
  65 static struct scatterlist *videobuf_vmalloc_to_sg(unsigned char
 *virt,
  66   int nr_pages)
  67 {
 
  ...
 
  77 for (i = 0; i  nr_pages; i++, virt += PAGE_SIZE) {
  78 pg = vmalloc_to_page(virt);
  79 if (NULL == pg)
  80 goto err;
  81 /* BUG_ON(PageHighMem(pg)); */
 
  ...
 
  96 static struct scatterlist *videobuf_pages_to_sg(struct page **pages,
  97 int nr_pages, int
 offset)
  98 {
 
  ...
 
  109 /* if (PageHighMem(pages[0])) */
  110 /* DMA to highmem pages might not work */
  111 /* goto highmem; */
  112 sg_set_page(sglist[0], pages[0], PAGE_SIZE - offset,
 offset);
  113 for (i = 1; i  nr_pages; i++) {
  114 if (NULL == pages[i])
  115 goto nopage;
  116 /* if (PageHighMem(pages[i]))
  117 goto highmem; */
  118 sg_set_page(sglist[i], pages[i], PAGE_SIZE, 0);
  119 }
 
  Can somebody shed any light on this?
 
 Sorry for taking so long to answer you.
 

Hey, no worries. That's fine.

 Basically, videobuf code were written at Linux 2.4 days, to be used by
 bttv driver (and later used by cx88 and saa7134). At that time, there
 where
 a hack for the usage of highmem (I think it was called bigmem or something
 like that).
 
 As I was not maintaining the code on that time, I'm not really sure what
 where
 the issues, but I suspect that this were an arch-implementation limit
 related to DMA transfers at highmem, on that time, due to x86 intrinsic
 limits. I'm not sure about the current limits of newer x86 chips, on 32
 and on 64 bits mode, but i think that this limit doesn't exist anymore.
 
 So, I suspect that just converting it to a call to dma_capable() should
 be enough to fix the issue.

Ok, sounds reasonable.

 
 Yet, as videobuf2 is almost ready for merge, maybe the best is to take
 some efforts on testing it, and to be sure that it doesn't contain any
 arch-specific limits inside its code.

So, do you want me to make a patch for this, or is this already taken care
on videobuf2?

Regards,
Sergio

 
 Cheers,
 Mauro
--
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: [omap3isp][PATCH v2 8/9] omap3isp: ccp2: Make SYSCONFIG fields consistent

2010-11-22 Thread Aguirre, Sergio
Hi,

 -Original Message-
 From: David Cohen [mailto:david.co...@nokia.com]
 Sent: Saturday, November 20, 2010 4:49 AM
 To: ext Laurent Pinchart
 Cc: Aguirre, Sergio; linux-media@vger.kernel.org
 Subject: Re: [omap3isp][PATCH v2 8/9] omap3isp: ccp2: Make SYSCONFIG
 fields consistent
 
 On Sat, Nov 20, 2010 at 11:34:04AM +0100, ext Laurent Pinchart wrote:
  Hi,
 
  On Saturday 20 November 2010 11:00:30 David Cohen wrote:
   On Sat, Nov 20, 2010 at 12:10:11AM +0100, ext Aguirre, Sergio wrote:
On Friday, November 19, 2010 9:44 AM Aguirre, Sergio wrote:
 On Friday, November 19, 2010 4:06 AM David Cohen wrote:
  On Mon, Nov 15, 2010 at 03:30:00PM +0100, ext Sergio Aguirre
 wrote:
   Signed-off-by: Sergio Aguirre saagui...@ti.com
   ---
  
drivers/media/video/isp/ispccp2.c |3 +--
drivers/media/video/isp/ispreg.h  |   14 --
2 files changed, 9 insertions(+), 8 deletions(-)
  
   diff --git a/drivers/media/video/isp/ispccp2.c
 
  b/drivers/media/video/isp/ispccp2.c
 
   index fa23394..3127a74 100644
   --- a/drivers/media/video/isp/ispccp2.c
   +++ b/drivers/media/video/isp/ispccp2.c
   @@ -419,8 +419,7 @@ static void ispccp2_mem_configure(struct
 
  isp_ccp2_device *ccp2,
 
 config-src_ofst = 0;
  
 }
  
   - isp_reg_writel(isp, (ISPCSI1_MIDLEMODE_SMARTSTANDBY 
   -ISPCSI1_MIDLEMODE_SHIFT),
   + isp_reg_writel(isp,
 ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SMART,
  
OMAP3_ISP_IOMEM_CCP2, ISPCCP2_SYSCONFIG);
 
  To make your cleanup even better, you could change
 isp_reg_clr_set()
  instead.
  If CCP2 MSTANDY_MODE is set to NOSTANDY, the result is going to
 be an
  invalid 0x3 value. Despite it cannot happen with the current
 code,
  it's still better to avoid such situations for future versions.
 :)

 Hmm you're right, I guess I didn't do any real functional changes,
 just
 defines renaming.

 I can repost an updated patch with this suggestion. No problem.
   
David,
   
Geez I guess I wasn't paying much attention to this either. Sorry.
   
The case you mention about it potentially become 0x3 is not
 possible,
because, I'm basically overwriting the whole register with (0x2 
 12)
Notice the isp_reg_write, there's no OR operation...
  
   That's correct. My mistake.
   IMO ISP power settings still need a better way to be setup, but it
   definitively does not belong to your cleanup patch.
   I'm fine with your changes.
  
Now, this means that we have been implicitly setting other fields as
Zeroes (SOFT_RESET = 0, and AUTO_IDLE = 0) aswell.
   
Has AUTOIDLE in CCP2 been tried in N900? I don't have a CCP2 sensor
 to
test with :(.
  
   I have no idea. Indeed, AUTOIDLE in ISP doesn't seem to be much
 reliable
   so far. It should be set to 0 until somebody proves it can be set to 1
 :)
 
  To summarize things, we're only setting the CCP2 AUTOIDLE bit on ES 1.0
  devices, and we're clearing it anyway ispccp2_mem_configure(). For the
 sake of
  correctness we should replace isp_reg_writel() by isp_reg_clr_set() in
  ispccp2_mem_configure(), which will only make a difference on ES 1.0
 devices
  that have basically no users. Is that OK with both of you ?

Yes, It's fine with me.

I'll say that if this doesn't change things for N900, which appears to be the 
only community available device (I know of) that uses CCP2 cameras, then we 
shouldn't care.

If somebody comes up with an ES1.0 in the future, and he does see problems,
then we will address that. But that would be a very weird case.

In fact, it will be most probably someone from TI with a hidden board buried
in some box of scraps, which happens to have hacked the board for a CCP2 
camera...

The more I think about it, the more I'm getting convinced this shouldn't be
a worry. :)

Regards,
Sergio

 
 I'm fine with both solutions.
 IMO power settings could be improved and not be hardcoded. It could come
 from
 platform data. But that's another case. :)
 
 Br,
 
 David
 
 
  --
  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
--
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: [omap3isp RFC][PATCH 1/4] omap3isp: Abstract isp subdevs clock control

2010-11-22 Thread Aguirre, Sergio


 -Original Message-
 From: David Cohen [mailto:david.co...@nokia.com]
 Sent: Saturday, November 20, 2010 5:27 AM
 To: Aguirre, Sergio
 Cc: Laurent Pinchart; linux-media@vger.kernel.org
 Subject: Re: [omap3isp RFC][PATCH 1/4] omap3isp: Abstract isp subdevs
 clock control
 
 Hi Sergio,

Hi David,

 
 Thanks for the patch. :)

Thanks for the review.

 
 On Sat, Nov 20, 2010 at 12:23:48AM +0100, ext Sergio Aguirre wrote:
  Submodules shouldn't be aware of global register bit structure,
  specially if the submodules are shared in the future with
  other TI architectures (Davinci, future OMAPs, etc)
 
  Signed-off-by: Sergio Aguirre saagui...@ti.com
  ---
   drivers/media/video/isp/isp.c|   54
 ++
   drivers/media/video/isp/isp.h|   12 +++
   drivers/media/video/isp/ispccdc.c|6 +--
   drivers/media/video/isp/isppreview.c |6 +--
   drivers/media/video/isp/ispresizer.c |6 +--
   5 files changed, 72 insertions(+), 12 deletions(-)
 
  diff --git a/drivers/media/video/isp/isp.c
 b/drivers/media/video/isp/isp.c
  index 30bdc48..2e5030f 100644
  --- a/drivers/media/video/isp/isp.c
  +++ b/drivers/media/video/isp/isp.c
  @@ -991,6 +991,60 @@ void isp_sbl_disable(struct isp_device *isp, enum
 isp_sbl_resource res)
* Clock management
*/
 
  +void isp_subclk_enable(struct isp_device *isp, enum isp_subclk_resource
 res)
  +{
  +   u32 clk = 0;
  +
  +   isp-subclk_resources |= res;
  +
  +   if (isp-subclk_resources  OMAP3_ISP_SUBCLK_H3A)
  +   clk |= ISPCTRL_H3A_CLK_EN;
  +
  +   if (isp-subclk_resources  OMAP3_ISP_SUBCLK_HIST)
  +   clk |= ISPCTRL_HIST_CLK_EN;
  +
  +   if (isp-subclk_resources  OMAP3_ISP_SUBCLK_RESIZER)
  +   clk |= ISPCTRL_RSZ_CLK_EN;
  +
  +   /* NOTE: For CCDC  Preview submodules, we need to affect internal
  +*   RAM aswell.
  +*/
  +   if (isp-subclk_resources  OMAP3_ISP_SUBCLK_CCDC)
  +   clk |= ISPCTRL_CCDC_CLK_EN | ISPCTRL_CCDC_RAM_EN;
  +
  +   if (isp-subclk_resources  OMAP3_ISP_SUBCLK_PREVIEW)
  +   clk |= ISPCTRL_PREV_CLK_EN | ISPCTRL_PREV_RAM_EN;
  +
  +   isp_reg_set(isp, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL, clk);
  +}
 
 To decrease the lines of code, you can create a new static function
 called e.g. isp_subclk_update(). It can be a copy of isp_subclk_enable()
 but removing the line where it changes 'isp-subclk_resources' and
 replacing 'isp_reg_set(isp, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL, clk)' by
 'isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL, clocks mask,
 clk)'.
 
 Then, isp_subclk_enable() can update isp-subclk_resources, call
 isp_subclk_update() and finish.

Sounds nicer.

Sure, I can redesign it that way. Thanks for the suggestion!

 
  +
  +void isp_subclk_disable(struct isp_device *isp, enum
 isp_subclk_resource res)
  +{
  +   u32 clk = 0;
  +
  +   isp-subclk_resources = ~res;
 
 Same here. This function can call isp_subclk_update() and end now.

Agreed.

 
  +
  +   if (!(isp-subclk_resources  OMAP3_ISP_SUBCLK_H3A))
  +   clk |= ISPCTRL_H3A_CLK_EN;
  +
  +   if (!(isp-subclk_resources  OMAP3_ISP_SUBCLK_HIST))
  +   clk |= ISPCTRL_HIST_CLK_EN;
  +
  +   if (!(isp-subclk_resources  OMAP3_ISP_SUBCLK_RESIZER))
  +   clk |= ISPCTRL_RSZ_CLK_EN;
  +
  +   /* NOTE: For CCDC  Preview submodules, we need to affect internal
  +*   RAM aswell.
  +*/
  +   if (!(isp-subclk_resources  OMAP3_ISP_SUBCLK_CCDC))
  +   clk |= ISPCTRL_CCDC_CLK_EN | ISPCTRL_CCDC_RAM_EN;
  +
  +   if (!(isp-subclk_resources  OMAP3_ISP_SUBCLK_PREVIEW))
  +   clk |= ISPCTRL_PREV_CLK_EN | ISPCTRL_PREV_RAM_EN;
  +
  +   isp_reg_clr(isp, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL, clk);
  +}
  +
   /*
* isp_enable_clocks - Enable ISP clocks
* @isp: OMAP3 ISP device
  diff --git a/drivers/media/video/isp/isp.h
 b/drivers/media/video/isp/isp.h
  index b8f63e2..1260e9f 100644
  --- a/drivers/media/video/isp/isp.h
  +++ b/drivers/media/video/isp/isp.h
  @@ -85,6 +85,14 @@ enum isp_sbl_resource {
  OMAP3_ISP_SBL_RESIZER_WRITE = 0x200,
   };
 
  +enum isp_subclk_resource {
  +   OMAP3_ISP_SUBCLK_CCDC   = 0x1,
  +   OMAP3_ISP_SUBCLK_H3A= 0x2,
  +   OMAP3_ISP_SUBCLK_HIST   = 0x4,
  +   OMAP3_ISP_SUBCLK_PREVIEW= 0x8,
  +   OMAP3_ISP_SUBCLK_RESIZER= 0x10,
 
 I'm fine with this way, but (1  0), (1  1), ... has a better
 readability.

I guess I just replicated above enum for consistency, but I agree that
your suggestion looks better.

I'll change it.

Obrigado,
Sergio

 
 Br,
 
 David Cohen
 
  +};
  +
   enum isp_interface_type {
  ISP_INTERFACE_PARALLEL,
  ISP_INTERFACE_CSI2A_PHY2,
  @@ -262,6 +270,7 @@ struct isp_device {
  struct isp_csiphy isp_csiphy2;
 
  unsigned int sbl_resources;
  +   unsigned int subclk_resources;
 
  struct iommu *iommu;
   };
  @@ -294,6 +303,9 @@ void isp_print_status(struct isp_device *isp);
   void isp_sbl_enable(struct isp_device *isp, enum

RE: [omap3isp RFC][PATCH 2/4] omap3isp: Move CCDC LSC prefetch wait to main isp code

2010-11-22 Thread Aguirre, Sergio
Hi David and Laurent,

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Saturday, November 20, 2010 11:29 AM
 To: David Cohen
 Cc: Aguirre, Sergio; linux-media@vger.kernel.org
 Subject: Re: [omap3isp RFC][PATCH 2/4] omap3isp: Move CCDC LSC prefetch
 wait to main isp code
 
 Hi David,
 
 On Saturday 20 November 2010 12:39:56 David Cohen wrote:
  On Sat, Nov 20, 2010 at 12:23:49AM +0100, ext Sergio Aguirre wrote:
   Since this sequence strictly touches ISP global registers, it's
   not really part of the same register address space than the CCDC.
  
   Do this check in main isp code instead.
  
   Signed-off-by: Sergio Aguirre saagui...@ti.com
   ---
  
drivers/media/video/isp/isp.c |   24 
drivers/media/video/isp/isp.h |2 ++
drivers/media/video/isp/ispccdc.c |   26 +-
3 files changed, 27 insertions(+), 25 deletions(-)
  
   diff --git a/drivers/media/video/isp/isp.c
   b/drivers/media/video/isp/isp.c index 2e5030f..ee45eb6 100644
   --- a/drivers/media/video/isp/isp.c
   +++ b/drivers/media/video/isp/isp.c
   @@ -339,6 +339,30 @@ void isphist_dma_done(struct isp_device *isp)
  
 }
  
}
  
   +int ispccdc_lsc_wait_prefetch(struct isp_device *isp)
 
  This is up to you, but to ensure this function now belongs to ISP core
  and not CCDC anymore, I would change the function name to something like
  isp_ccdc_lsc_wait_prefetch().
  isp_* is prefix for ISP core and ispccdc_* is prefix for CCDC driver.
  I know we have the isphist_dma_done() inside ISP core, but changing it
  to isp_hist_dma_done could be a good cleanup as well.
  But this is my opinion only. :)
 
 I agree. I plan to submit a patch at some point that will rename all non-
 static functions to use the omap3isp_ prefix instead of the isp_ prefix.
 Static functions should use the module name as prefix (ccdc_, preview_,
 ...).

Sounds good.

 
 It will be a simple patch but will conflict with pretty much everything,
 so
 I'll try to push at at a quiet time (or at least quiet enough) to minimize
 disturbances. I will also see if I can use spatch [1] to generate it.

Ok, so, sounds to me then this leaves my patch as-is, and we'll wait for
Laurent's coccinelle-assisted changes on top in the future.

Is that correct?

Regards,
Sergio

 
 
 [1] http://coccinelle.lip6.fr/
 
 --
 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: [omap3isp RFC][PATCH 0/4] Improve inter subdev interaction

2010-11-22 Thread Aguirre, Sergio


 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Saturday, November 20, 2010 11:31 AM
 To: David Cohen
 Cc: Aguirre, Sergio; linux-media@vger.kernel.org
 Subject: Re: [omap3isp RFC][PATCH 0/4] Improve inter subdev interaction
 
 Hi David,
 
 On Saturday 20 November 2010 12:44:27 David Cohen wrote:
  On Sat, Nov 20, 2010 at 12:23:47AM +0100, ext Sergio Aguirre wrote:
   Hi,
  
   These are some patches to make these operations more generic:
   - Clock control is being controlled in a very crude manner by
  
 subdevices, it should be centralized in isp.c.
  
   - LSC prefetch wait check is reading a main ISP register, so move
  
 it to isp.c
  
   - Abstract SBL busy check: we don't want a submodule thinkering
  
 with main ISP registers. That should be done in the main isp.c
  
   Also, remove main ISP register dump from CSI2 specific dump. We
   should be using isp_print_status if we'll like to know main ISP
   regdump.
  
   Comments are welcome. More cleanups for better subdevice isolation
   are on the way.
 
  Your patches are fine for me. I sent you some comments, but they are
  opitional and it's up to you to decide what to do. :)
  You can copy linux-omap@ as well in future patches.

David and Laurent,

I appreciate a lot your review time and comments.

 
 I will try to submit the next version of the omap3isp driver for upstream
 review, either at the end of the weekend or on Monday. I will cross-post
 the
 driver to linux-media, linux-omap and LKML. Let's be ready to defend the
 media
 controller and the omap3isp driver :-)

Yeah! :)

 
 Until then let's not spam linux-omap with patches for a driver they don't
 know
 about.

Agreed.

Regards,
Sergio

 
 --
 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: [omap3isp RFC][PATCH 2/4] omap3isp: Move CCDC LSC prefetch wait to main isp code

2010-11-22 Thread Aguirre, Sergio
Hi Laurent,

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Monday, November 22, 2010 9:35 AM
 To: Aguirre, Sergio
 Cc: David Cohen; linux-media@vger.kernel.org
 Subject: Re: [omap3isp RFC][PATCH 2/4] omap3isp: Move CCDC LSC prefetch
 wait to main isp code
 
 Hi Sergio,
 
 On Monday 22 November 2010 16:29:46 Aguirre, Sergio wrote:
  On Saturday, November 20, 2010 11:29 AM Aguirre, Sergio wrote:
   On Saturday 20 November 2010 12:39:56 David Cohen wrote:
On Sat, Nov 20, 2010 at 12:23:49AM +0100, ext Sergio Aguirre wrote:
 Since this sequence strictly touches ISP global registers, it's
 not really part of the same register address space than the CCDC.

 Do this check in main isp code instead.

 Signed-off-by: Sergio Aguirre saagui...@ti.com
 ---

  drivers/media/video/isp/isp.c |   24 
  drivers/media/video/isp/isp.h |2 ++
  drivers/media/video/isp/ispccdc.c |   26 +---
 --
  3 files changed, 27 insertions(+), 25 deletions(-)

 diff --git a/drivers/media/video/isp/isp.c
 b/drivers/media/video/isp/isp.c index 2e5030f..ee45eb6 100644
 --- a/drivers/media/video/isp/isp.c
 +++ b/drivers/media/video/isp/isp.c
 @@ -339,6 +339,30 @@ void isphist_dma_done(struct isp_device *isp)

   }

  }

 +int ispccdc_lsc_wait_prefetch(struct isp_device *isp)
   
This is up to you, but to ensure this function now belongs to ISP
 core
and not CCDC anymore, I would change the function name to something
like isp_ccdc_lsc_wait_prefetch().
isp_* is prefix for ISP core and ispccdc_* is prefix for CCDC
 driver.
I know we have the isphist_dma_done() inside ISP core, but changing
 it
to isp_hist_dma_done could be a good cleanup as well.
But this is my opinion only. :)
  
   I agree. I plan to submit a patch at some point that will rename all
 non-
   static functions to use the omap3isp_ prefix instead of the isp_
 prefix.
   Static functions should use the module name as prefix (ccdc_,
 preview_,
   ...).
 
  Sounds good.
 
   It will be a simple patch but will conflict with pretty much
 everything,
   so
   I'll try to push at at a quiet time (or at least quiet enough) to
   minimize disturbances. I will also see if I can use spatch [1] to
   generate it.
 
  Ok, so, sounds to me then this leaves my patch as-is, and we'll wait for
  Laurent's coccinelle-assisted changes on top in the future.
 
  Is that correct?
 
 As you need to resubmit the serie anyway, I'd appreciate if you could
 already
 make the change.

Ok, sure. Not a problem for me.

Will add that change in v2 of this patch series.

Thanks for the clarification.

Regards,
Sergio

 
 --
 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


Please ignore... (RE: [omap3isp RFC][PATCH v2 0/4] Improve inter subdev interaction)

2010-11-22 Thread Aguirre, Sergio

 -Original Message-
 From: Aguirre, Sergio
 Sent: Monday, November 22, 2010 1:48 PM
 To: Laurent Pinchart
 Cc: linux-media@vger.kernel.org; David Cohen; Aguirre, Sergio
 Subject: [omap3isp RFC][PATCH v2 0/4] Improve inter subdev interaction
 
 Hi,
 
 These are some patches to make these operations more generic:
 - Clock control is being controlled in a very crude manner by
   subdevices, it should be centralized in isp.c.
 - LSC prefetch wait check is reading a main ISP register, so move
   it to isp.c
 - Abstract SBL busy check: we don't want a submodule thinkering
   with main ISP registers. That should be done in the main isp.c
 
 Also, remove main ISP register dump from CSI2 specific dump. We
 should be using isp_print_status if we'll like to know main ISP
 regdump.
 
 Comments are welcome. More cleanups for better subdevice isolation
 are on the way.
 
 Regards,
 Sergio

Oops, I resent the same patches with just an updated cover letter...

I'm resending the correct ones now... Please ignore this patch series.

I'm very sorry for the spamming.

Regards,
Sergio

 
 Changelog:
 v2:
 - Improved logic in isp subdevs clock control (Thanks David Cohen)
 - Renamed ispccdc_lsc_wait_prefetch - isp_ccdc_* to be clear on
   function declaration new location (isp.c) (Thanks David and Laurent)
 
 v1:
 - Initial version
 
 Sergio Aguirre (4):
   omap3isp: Abstract isp subdevs clock control
   omap3isp: Move CCDC LSC prefetch wait to main isp code
   omap3isp: sbl: Abstract SBL busy check
   omap3isp: csi2: Don't dump ISP main registers
 
  drivers/media/video/isp/isp.c|   95
 ++
  drivers/media/video/isp/isp.h|   16 ++
  drivers/media/video/isp/ispccdc.c|   42 ++-
  drivers/media/video/isp/ispcsi2.c|7 ---
  drivers/media/video/isp/isppreview.c |6 +--
  drivers/media/video/isp/ispresizer.c |6 +--
  6 files changed, 119 insertions(+), 53 deletions(-)

--
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: [omap3isp][PATCH v2 8/9] omap3isp: ccp2: Make SYSCONFIG fields consistent

2010-11-19 Thread Aguirre, Sergio

 -Original Message-
 From: David Cohen [mailto:david.co...@nokia.com]
 Sent: Friday, November 19, 2010 4:06 AM
 To: Aguirre, Sergio
 Cc: Laurent Pinchart; linux-media@vger.kernel.org
 Subject: Re: [omap3isp][PATCH v2 8/9] omap3isp: ccp2: Make SYSCONFIG
 fields consistent
 
 Hi Sergio,

Hi David,

Thanks for the review.

 
 I've few comments below.
 
 On Mon, Nov 15, 2010 at 03:30:00PM +0100, ext Sergio Aguirre wrote:
  Signed-off-by: Sergio Aguirre saagui...@ti.com
  ---
   drivers/media/video/isp/ispccp2.c |3 +--
   drivers/media/video/isp/ispreg.h  |   14 --
   2 files changed, 9 insertions(+), 8 deletions(-)
 
  diff --git a/drivers/media/video/isp/ispccp2.c
 b/drivers/media/video/isp/ispccp2.c
  index fa23394..3127a74 100644
  --- a/drivers/media/video/isp/ispccp2.c
  +++ b/drivers/media/video/isp/ispccp2.c
  @@ -419,8 +419,7 @@ static void ispccp2_mem_configure(struct
 isp_ccp2_device *ccp2,
  config-src_ofst = 0;
  }
 
  -   isp_reg_writel(isp, (ISPCSI1_MIDLEMODE_SMARTSTANDBY 
  -  ISPCSI1_MIDLEMODE_SHIFT),
  +   isp_reg_writel(isp, ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SMART,
 OMAP3_ISP_IOMEM_CCP2, ISPCCP2_SYSCONFIG);
 
 To make your cleanup even better, you could change isp_reg_clr_set()
 instead.
 If CCP2 MSTANDY_MODE is set to NOSTANDY, the result is going to be an
 invalid 0x3 value. Despite it cannot happen with the current code, it's
 still better to avoid such situations for future versions. :)

Hmm you're right, I guess I didn't do any real functional changes, just defines 
renaming.

I can repost an updated patch with this suggestion. No problem.

 
 
  /* Hsize, Skip */
  diff --git a/drivers/media/video/isp/ispreg.h
 b/drivers/media/video/isp/ispreg.h
  index d885541..9b0d3ad 100644
  --- a/drivers/media/video/isp/ispreg.h
  +++ b/drivers/media/video/isp/ispreg.h
  @@ -141,6 +141,14 @@
   #define ISPCCP2_REVISION   (0x000)
   #define ISPCCP2_SYSCONFIG  (0x004)
   #define ISPCCP2_SYSCONFIG_SOFT_RESET   (1  1)
  +#define ISPCCP2_SYSCONFIG_AUTO_IDLE0x1
  +#define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SHIFT  12
  +#define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_FORCE  \
  +   (0x0  ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SHIFT)
  +#define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_NO \
  +   (0x1  ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SHIFT)
  +#define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SMART  \
  +   (0x2  ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SHIFT)
 
 You can add some ISPCCP2_SYSCONFIG_MSTANDY_MODE_MASK, as 2 bits must be
 always set together.

Sure, will do.

Thanks and Regards,
Sergio

 
 Regards,
 
 David Cohen
 
   #define ISPCCP2_SYSSTATUS  (0x008)
   #define ISPCCP2_SYSSTATUS_RESET_DONE   (1  0)
   #define ISPCCP2_LC01_IRQENABLE (0x00C)
  @@ -1309,12 +1317,6 @@
   #define ISPMMU_SIDLEMODE_SMARTIDLE 2
   #define ISPMMU_SIDLEMODE_SHIFT 3
 
  -#define ISPCSI1_AUTOIDLE   0x1
  -#define ISPCSI1_MIDLEMODE_SHIFT12
  -#define ISPCSI1_MIDLEMODE_FORCESTANDBY 0x0
  -#define ISPCSI1_MIDLEMODE_NOSTANDBY0x1
  -#define ISPCSI1_MIDLEMODE_SMARTSTANDBY 0x2
  -
   /* 
 -
* CSI2 receiver registers (ES2.0)
*/
  --
  1.7.0.4
 
  --
  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
--
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: [omap3isp][PATCH v2 7/9] omap3isp: Cleanup isp_power_settings

2010-11-19 Thread Aguirre, Sergio


 -Original Message-
 From: David Cohen [mailto:david.co...@nokia.com]
 Sent: Friday, November 19, 2010 4:18 AM
 To: Aguirre, Sergio
 Cc: Laurent Pinchart; linux-media@vger.kernel.org
 Subject: Re: [omap3isp][PATCH v2 7/9] omap3isp: Cleanup isp_power_settings
 
 Hi Sergio,
 
 Thanks for the patch.

Hi David,

Thanks for the comments.

 
 On Mon, Nov 15, 2010 at 03:29:59PM +0100, ext Sergio Aguirre wrote:
  1. Get rid of CSI2 / CCP2 power settings, as they are controlled
 in the receivers code anyways.
 
 CCP2 is not correctly handling this. It's setting SMART STANDBY mode one
 when reading from memory. You should fix it before remove such code from
 ISP core driver.

Ok, agreed.

I'll generate a new patch before this to compensate that. Not a problem.

 
  2. Avoid code duplication.
 
 Agree. But only after considering the comment above.

Ok.

Thanks and Regards,
Sergio

 
 Regards,
 
 David
 
 
  Signed-off-by: Sergio Aguirre saagui...@ti.com
  ---
   drivers/media/video/isp/isp.c |   49 ++
 ---
   1 files changed, 7 insertions(+), 42 deletions(-)
 
  diff --git a/drivers/media/video/isp/isp.c
 b/drivers/media/video/isp/isp.c
  index de9352b..30bdc48 100644
  --- a/drivers/media/video/isp/isp.c
  +++ b/drivers/media/video/isp/isp.c
  @@ -254,48 +254,13 @@ EXPORT_SYMBOL(isp_set_xclk);
*/
   static void isp_power_settings(struct isp_device *isp, int idle)
   {
  -   if (idle) {
  -   isp_reg_writel(isp,
  -  (ISP_SYSCONFIG_MIDLEMODE_SMARTSTANDBY 
  -   ISP_SYSCONFIG_MIDLEMODE_SHIFT),
  -  OMAP3_ISP_IOMEM_MAIN, ISP_SYSCONFIG);
  -   if (omap_rev() == OMAP3430_REV_ES1_0) {
  -   isp_reg_writel(isp, ISPCSI1_AUTOIDLE |
  -  (ISPCSI1_MIDLEMODE_SMARTSTANDBY 
  -   ISPCSI1_MIDLEMODE_SHIFT),
  -  OMAP3_ISP_IOMEM_CSI2A_REGS1,
  -  ISPCSI2_SYSCONFIG);
  -   isp_reg_writel(isp, ISPCSI1_AUTOIDLE |
  -  (ISPCSI1_MIDLEMODE_SMARTSTANDBY 
  -   ISPCSI1_MIDLEMODE_SHIFT),
  -  OMAP3_ISP_IOMEM_CCP2,
  -  ISPCCP2_SYSCONFIG);
  -   }
  -   isp_reg_writel(isp, ISPCTRL_SBL_AUTOIDLE,
 OMAP3_ISP_IOMEM_MAIN,
  -  ISP_CTRL);
  -
  -   } else {
  -   isp_reg_writel(isp,
  -  (ISP_SYSCONFIG_MIDLEMODE_FORCESTANDBY 
  -   ISP_SYSCONFIG_MIDLEMODE_SHIFT),
  -  OMAP3_ISP_IOMEM_MAIN, ISP_SYSCONFIG);
  -   if (omap_rev() == OMAP3430_REV_ES1_0) {
  -   isp_reg_writel(isp, ISPCSI1_AUTOIDLE |
  -  (ISPCSI1_MIDLEMODE_FORCESTANDBY 
  -   ISPCSI1_MIDLEMODE_SHIFT),
  -  OMAP3_ISP_IOMEM_CSI2A_REGS1,
  -  ISPCSI2_SYSCONFIG);
  -
  -   isp_reg_writel(isp, ISPCSI1_AUTOIDLE |
  -  (ISPCSI1_MIDLEMODE_FORCESTANDBY 
  -   ISPCSI1_MIDLEMODE_SHIFT),
  -  OMAP3_ISP_IOMEM_CCP2,
  -  ISPCCP2_SYSCONFIG);
  -   }
  -
  -   isp_reg_writel(isp, ISPCTRL_SBL_AUTOIDLE,
 OMAP3_ISP_IOMEM_MAIN,
  -  ISP_CTRL);
  -   }
  +   isp_reg_writel(isp,
  +  ((idle ? ISP_SYSCONFIG_MIDLEMODE_SMARTSTANDBY :
  +   ISP_SYSCONFIG_MIDLEMODE_FORCESTANDBY) 
  +   ISP_SYSCONFIG_MIDLEMODE_SHIFT),
  +  OMAP3_ISP_IOMEM_MAIN, ISP_SYSCONFIG);
  +   isp_reg_writel(isp, ISPCTRL_SBL_AUTOIDLE, OMAP3_ISP_IOMEM_MAIN,
  +  ISP_CTRL);
   }
 
   /*
  --
  1.7.0.4
 
  --
  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
--
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: [omap3isp][PATCH v2 5/9] omap3isp: Remove unused CBUFF register access

2010-11-19 Thread Aguirre, Sergio
Hi Laurent and David,

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Friday, November 19, 2010 4:33 AM
 To: David Cohen
 Cc: Aguirre, Sergio; linux-media@vger.kernel.org
 Subject: Re: [omap3isp][PATCH v2 5/9] omap3isp: Remove unused CBUFF
 register access
 
 Hi David,
 
 On Friday 19 November 2010 11:19:44 David Cohen wrote:
  On Mon, Nov 15, 2010 at 03:29:57PM +0100, ext Sergio Aguirre wrote:
 
 [snip]
 
   @@ -244,26 +239,6 @@
  
#define ISP_CSIB_SYSCONFIG   ISPCCP2_SYSCONFIG
#define ISP_CSIA_SYSCONFIG   ISPCSI2_SYSCONFIG
  
   -/* ISP_CBUFF Registers */
   -
   -#define ISP_CBUFF_SYSCONFIG  (0x010)
   -#define ISP_CBUFF_IRQENABLE  (0x01C)
   -
   -#define ISP_CBUFF0_CTRL  (0x020)
   -#define ISP_CBUFF1_CTRL  (0x024)
   -
   -#define ISP_CBUFF0_START (0x040)
   -#define ISP_CBUFF1_START (0x044)
   -
   -#define ISP_CBUFF0_END   (0x050)
   -#define ISP_CBUFF1_END   (0x054)
   -
   -#define ISP_CBUFF0_WINDOWSIZE(0x060)
   -#define ISP_CBUFF1_WINDOWSIZE(0x064)
   -
   -#define ISP_CBUFF0_THRESHOLD (0x070)
   -#define ISP_CBUFF1_THRESHOLD (0x074)
   -
 
  No need to remove the registers from header file. We're not using them
  on current version, but it doesn't mean we won't use ever. :)
 
 I would have made the same comment for other registers, but we're not
 using
 the CBUFF module at all here, with no plans to use it in the future. It
 might
 not be worth it keeping the register definitions. I have no strong feeling
 about it, I'm fine with both choices.

David,

IMO, we should not introduce dead code/unusued defines in the first omap3isp
upstream version. I think it's already quite hard to review for somebody
outside the omap3isp development team.

Having all this just in case will most probably end up in bulk, as we
might never implement the CBUFF HW block, as Laurent mentions.

I'll be more biased on all this being re-added if we end up implementing a 
ispcbuff submodule.

Regards,
Sergio


 
 --
 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


[omap3isp] Prefered patch base for latest code? (was: RE: Translation faults with OMAP ISP)

2010-11-19 Thread Aguirre, Sergio
Hi David and Laurent,

snip

 
  Don't forget that Lane is using an older version of the OMAP3 ISP
 driver. The
  bug might have been fixed in the latest code.
 
 Hm. We did fix some iommu faults.
 Maybe it's better to test a newer version instead.
 If you still see that bug using an up-to-date version, please report it
 and I can try to help you. :)

How close is this tree from the latest internal version you guys work with?

http://meego.gitorious.com/maemo-multimedia/omap3isp-rx51/commits/devel

I have been basing my patches on top of this tree:

http://git.linuxtv.org/pinchartl/media.git?h=refs/heads/media-0004-omap3isp

Would it be better to be based on the gitorious tree instead?

What do you think?

Regards,
Sergio

 
 Regards,
 
 David
 
 
  --
  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
--
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: [omap3isp] Prefered patch base for latest code? (was: RE: Translation faults with OMAP ISP)

2010-11-19 Thread Aguirre, Sergio
Hi Laurent,

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Friday, November 19, 2010 10:16 AM
 To: Aguirre, Sergio
 Cc: David Cohen; ext Lane Brooks; linux-media@vger.kernel.org
 Subject: Re: [omap3isp] Prefered patch base for latest code? (was: RE:
 Translation faults with OMAP ISP)
 
 Hi Sergio,
 
 On Friday 19 November 2010 17:07:09 Aguirre, Sergio wrote:
  Hi David and Laurent,
 
  snip
 
Don't forget that Lane is using an older version of the OMAP3 ISP
driver. The bug might have been fixed in the latest code.
  
   Hm. We did fix some iommu faults.
   Maybe it's better to test a newer version instead.
   If you still see that bug using an up-to-date version, please report
 it
   and I can try to help you. :)
 
  How close is this tree from the latest internal version you guys work
 with?
 
  http://meego.gitorious.com/maemo-multimedia/omap3isp-rx51/commits/devel
 
 There's less differences between gitorious and our internal tree than
 between
 linuxtv and our internal tree.

Ok, I guess I can treat above tree as an omap3isp-next tree then, to have
a sneak preview of what's coming ;)

 
  I have been basing my patches on top of this tree:
 
  http://git.linuxtv.org/pinchartl/media.git?h=refs/heads/media-0004-
 omap3isp
 
  Would it be better to be based on the gitorious tree instead?
 
  What do you think?
 
 I will push a big patch that ports all the changes made to the MC and V4L2
 core, as well as omap3-isp driver, during public review to our internal
 tree
 early next week (should be on Monday). The trees will then get in sync.
 The
 gitorious tree will be updated as well.
 
 Unless you want your patches to be applied before Monday, which won't
 happen
 anyway, please base them on the linuxtv tree :-)

Ok, sure. It's better for me, since the gitorious devel tree includes rx51
support which I don't even have a device to try it out :P

I'll continue to be based on media-0004-omap3isp branch then, and just watch
devel branch to know if I'm not doing something conflicting.

Regards,
Sergio
 
 --
 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: [omap3isp] Prefered patch base for latest code? (was: RE: Translation faults with OMAP ISP)

2010-11-19 Thread Aguirre, Sergio
Hi Laurent,

 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
 Sent: Friday, November 19, 2010 10:32 AM
 To: Aguirre, Sergio
 Cc: David Cohen; ext Lane Brooks; linux-media@vger.kernel.org
 Subject: Re: [omap3isp] Prefered patch base for latest code? (was: RE:
 Translation faults with OMAP ISP)
 
 Hi Sergio,
 
 On Friday 19 November 2010 17:23:45 Aguirre, Sergio wrote:
  On Friday, November 19, 2010 10:16 AM Aguirre, Sergio wrote:
   On Friday 19 November 2010 17:07:09 Aguirre, Sergio wrote:
 
 [snip]
 
How close is this tree from the latest internal version you guys
 work
with?
   
http://meego.gitorious.com/maemo-multimedia/omap3isp-
 rx51/commits/devel
  
   There's less differences between gitorious and our internal tree than
   between linuxtv and our internal tree.
 
  Ok, I guess I can treat above tree as an omap3isp-next tree then, to
 have
  a sneak preview of what's coming ;)
 
 I haven't expressed myself clearly enough. The gitorious tree is currently
 more in sync with our internal tree that the linuxtv is for a simple
 reason:
 both our internal tree and the gitorious tree are missing modifications
 made
 during the public review process.

Ok. Sorry, I think I didn't quite understood that.

 
 Patches published from our internal tree are always pushed to linuxtv and
 gitorious at the same time (or mostly). Please don't use the gitorious
 tree
 for anything else than trying the driver on the N900.

I see. So I probably won't worry about this tree at all, since I don't have an 
N900.

I'm trying this in my Zoom board w/OMAP3630, and I have a Beagleboard xM handy 
aswell (OMAP3730), so In my tree I'll try to keep support for both of
These.

Also, I'm working on trying to bring this in a very different chip, but that's 
a secret ;) That's why I'm working in doing cleanups.

Regards,
Sergio

 
 --
 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
--
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: [omap3isp][PATCH v2 7/9] omap3isp: Cleanup isp_power_settings

2010-11-19 Thread Aguirre, Sergio


 -Original Message-
 From: Aguirre, Sergio
 Sent: Friday, November 19, 2010 9:46 AM
 To: 'David Cohen'
 Cc: Laurent Pinchart; linux-media@vger.kernel.org
 Subject: RE: [omap3isp][PATCH v2 7/9] omap3isp: Cleanup isp_power_settings
  -Original Message-
  From: David Cohen [mailto:david.co...@nokia.com]
  Sent: Friday, November 19, 2010 4:18 AM
  To: Aguirre, Sergio
  Cc: Laurent Pinchart; linux-media@vger.kernel.org
  Subject: Re: [omap3isp][PATCH v2 7/9] omap3isp: Cleanup
 isp_power_settings
 
  Hi Sergio,
 
  Thanks for the patch.
 
 Hi David,
 
 Thanks for the comments.
 
 
  On Mon, Nov 15, 2010 at 03:29:59PM +0100, ext Sergio Aguirre wrote:
   1. Get rid of CSI2 / CCP2 power settings, as they are controlled
  in the receivers code anyways.
 
  CCP2 is not correctly handling this. It's setting SMART STANDBY mode one
  when reading from memory. You should fix it before remove such code from
  ISP core driver.
 
 Ok, agreed.
 
 I'll generate a new patch before this to compensate that. Not a problem.

Is N900 seeing any functional difference w/ this patch?

Actually, I reanalyzed the patch, and this code should be unexecuted, since
it is conditioned to 3430 ES1.0 chip (omap_rev() == OMAP3430_REV_ES1_0),
which I don't think much people has access. And not definitely any
production quality device.

Even the N900 is using ES3.1 or something like that AFAIK.

So, It should not make any functional difference, unless you have an ES1.0.

Regards,
Sergio

 
 
   2. Avoid code duplication.
 
  Agree. But only after considering the comment above.
 
 Ok.
 
 Thanks and Regards,
 Sergio
 
 
  Regards,
 
  David
 
  
   Signed-off-by: Sergio Aguirre saagui...@ti.com
   ---
drivers/media/video/isp/isp.c |   49 ++--
 --
  ---
1 files changed, 7 insertions(+), 42 deletions(-)
  
   diff --git a/drivers/media/video/isp/isp.c
  b/drivers/media/video/isp/isp.c
   index de9352b..30bdc48 100644
   --- a/drivers/media/video/isp/isp.c
   +++ b/drivers/media/video/isp/isp.c
   @@ -254,48 +254,13 @@ EXPORT_SYMBOL(isp_set_xclk);
 */
static void isp_power_settings(struct isp_device *isp, int idle)
{
   - if (idle) {
   - isp_reg_writel(isp,
   -(ISP_SYSCONFIG_MIDLEMODE_SMARTSTANDBY 
   - ISP_SYSCONFIG_MIDLEMODE_SHIFT),
   -OMAP3_ISP_IOMEM_MAIN, ISP_SYSCONFIG);
   - if (omap_rev() == OMAP3430_REV_ES1_0) {
   - isp_reg_writel(isp, ISPCSI1_AUTOIDLE |
   -(ISPCSI1_MIDLEMODE_SMARTSTANDBY 
   - ISPCSI1_MIDLEMODE_SHIFT),
   -OMAP3_ISP_IOMEM_CSI2A_REGS1,
   -ISPCSI2_SYSCONFIG);
   - isp_reg_writel(isp, ISPCSI1_AUTOIDLE |
   -(ISPCSI1_MIDLEMODE_SMARTSTANDBY 
   - ISPCSI1_MIDLEMODE_SHIFT),
   -OMAP3_ISP_IOMEM_CCP2,
   -ISPCCP2_SYSCONFIG);
   - }
   - isp_reg_writel(isp, ISPCTRL_SBL_AUTOIDLE,
  OMAP3_ISP_IOMEM_MAIN,
   -ISP_CTRL);
   -
   - } else {
   - isp_reg_writel(isp,
   -(ISP_SYSCONFIG_MIDLEMODE_FORCESTANDBY 
   - ISP_SYSCONFIG_MIDLEMODE_SHIFT),
   -OMAP3_ISP_IOMEM_MAIN, ISP_SYSCONFIG);
   - if (omap_rev() == OMAP3430_REV_ES1_0) {
   - isp_reg_writel(isp, ISPCSI1_AUTOIDLE |
   -(ISPCSI1_MIDLEMODE_FORCESTANDBY 
   - ISPCSI1_MIDLEMODE_SHIFT),
   -OMAP3_ISP_IOMEM_CSI2A_REGS1,
   -ISPCSI2_SYSCONFIG);
   -
   - isp_reg_writel(isp, ISPCSI1_AUTOIDLE |
   -(ISPCSI1_MIDLEMODE_FORCESTANDBY 
   - ISPCSI1_MIDLEMODE_SHIFT),
   -OMAP3_ISP_IOMEM_CCP2,
   -ISPCCP2_SYSCONFIG);
   - }
   -
   - isp_reg_writel(isp, ISPCTRL_SBL_AUTOIDLE,
  OMAP3_ISP_IOMEM_MAIN,
   -ISP_CTRL);
   - }
   + isp_reg_writel(isp,
   +((idle ? ISP_SYSCONFIG_MIDLEMODE_SMARTSTANDBY :
   + ISP_SYSCONFIG_MIDLEMODE_FORCESTANDBY) 
   + ISP_SYSCONFIG_MIDLEMODE_SHIFT),
   +OMAP3_ISP_IOMEM_MAIN, ISP_SYSCONFIG);
   + isp_reg_writel(isp, ISPCTRL_SBL_AUTOIDLE, OMAP3_ISP_IOMEM_MAIN,
   +ISP_CTRL);
}
  
/*
   --
   1.7.0.4
  
   --
   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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body

RE: [omap3isp][PATCH v2 8/9] omap3isp: ccp2: Make SYSCONFIG fields consistent

2010-11-19 Thread Aguirre, Sergio


 -Original Message-
 From: Aguirre, Sergio
 Sent: Friday, November 19, 2010 9:44 AM
 To: 'David Cohen'
 Cc: Laurent Pinchart; linux-media@vger.kernel.org
 Subject: RE: [omap3isp][PATCH v2 8/9] omap3isp: ccp2: Make SYSCONFIG
 fields consistent
 
 
  -Original Message-
  From: David Cohen [mailto:david.co...@nokia.com]
  Sent: Friday, November 19, 2010 4:06 AM
  To: Aguirre, Sergio
  Cc: Laurent Pinchart; linux-media@vger.kernel.org
  Subject: Re: [omap3isp][PATCH v2 8/9] omap3isp: ccp2: Make SYSCONFIG
  fields consistent
 
  Hi Sergio,
 
 Hi David,
 
 Thanks for the review.
 
 
  I've few comments below.
 
  On Mon, Nov 15, 2010 at 03:30:00PM +0100, ext Sergio Aguirre wrote:
   Signed-off-by: Sergio Aguirre saagui...@ti.com
   ---
drivers/media/video/isp/ispccp2.c |3 +--
drivers/media/video/isp/ispreg.h  |   14 --
2 files changed, 9 insertions(+), 8 deletions(-)
  
   diff --git a/drivers/media/video/isp/ispccp2.c
  b/drivers/media/video/isp/ispccp2.c
   index fa23394..3127a74 100644
   --- a/drivers/media/video/isp/ispccp2.c
   +++ b/drivers/media/video/isp/ispccp2.c
   @@ -419,8 +419,7 @@ static void ispccp2_mem_configure(struct
  isp_ccp2_device *ccp2,
 config-src_ofst = 0;
 }
  
   - isp_reg_writel(isp, (ISPCSI1_MIDLEMODE_SMARTSTANDBY 
   -ISPCSI1_MIDLEMODE_SHIFT),
   + isp_reg_writel(isp, ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SMART,
OMAP3_ISP_IOMEM_CCP2, ISPCCP2_SYSCONFIG);
 
  To make your cleanup even better, you could change isp_reg_clr_set()
  instead.
  If CCP2 MSTANDY_MODE is set to NOSTANDY, the result is going to be an
  invalid 0x3 value. Despite it cannot happen with the current code, it's
  still better to avoid such situations for future versions. :)
 
 Hmm you're right, I guess I didn't do any real functional changes, just
 defines renaming.
 
 I can repost an updated patch with this suggestion. No problem.

David,

Geez I guess I wasn't paying much attention to this either. Sorry.

The case you mention about it potentially become 0x3 is not possible, because, 
I'm basically overwriting the whole register with (0x2  12)
Notice the isp_reg_write, there's no OR operation...

Now, this means that we have been implicitly setting other fields as Zeroes 
(SOFT_RESET = 0, and AUTO_IDLE = 0) aswell.

Has AUTOIDLE in CCP2 been tried in N900? I don't have a CCP2 sensor to test
with :(.

Regards,
Sergio

 
 
  
 /* Hsize, Skip */
   diff --git a/drivers/media/video/isp/ispreg.h
  b/drivers/media/video/isp/ispreg.h
   index d885541..9b0d3ad 100644
   --- a/drivers/media/video/isp/ispreg.h
   +++ b/drivers/media/video/isp/ispreg.h
   @@ -141,6 +141,14 @@
#define ISPCCP2_REVISION (0x000)
#define ISPCCP2_SYSCONFIG(0x004)
#define ISPCCP2_SYSCONFIG_SOFT_RESET (1  1)
   +#define ISPCCP2_SYSCONFIG_AUTO_IDLE  0x1
   +#define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SHIFT12
   +#define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_FORCE\
   + (0x0  ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SHIFT)
   +#define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_NO   \
   + (0x1  ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SHIFT)
   +#define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SMART\
   + (0x2  ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SHIFT)
 
  You can add some ISPCCP2_SYSCONFIG_MSTANDY_MODE_MASK, as 2 bits must be
  always set together.
 
 Sure, will do.
 
 Thanks and Regards,
 Sergio
 
 
  Regards,
 
  David Cohen
 
#define ISPCCP2_SYSSTATUS(0x008)
#define ISPCCP2_SYSSTATUS_RESET_DONE (1  0)
#define ISPCCP2_LC01_IRQENABLE   (0x00C)
   @@ -1309,12 +1317,6 @@
#define ISPMMU_SIDLEMODE_SMARTIDLE   2
#define ISPMMU_SIDLEMODE_SHIFT   3
  
   -#define ISPCSI1_AUTOIDLE 0x1
   -#define ISPCSI1_MIDLEMODE_SHIFT  12
   -#define ISPCSI1_MIDLEMODE_FORCESTANDBY   0x0
   -#define ISPCSI1_MIDLEMODE_NOSTANDBY  0x1
   -#define ISPCSI1_MIDLEMODE_SMARTSTANDBY   0x2
   -
/* --
 --
  -
 * CSI2 receiver registers (ES2.0)
 */
   --
   1.7.0.4
  
   --
   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
--
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: [omap3isp RFC][PATCH 1/4] omap3isp: Abstract isp subdevs clock control

2010-11-19 Thread Aguirre, Sergio


 -Original Message-
 From: Aguirre, Sergio
 Sent: Friday, November 19, 2010 5:24 PM
 To: Laurent Pinchart
 Cc: linux-media@vger.kernel.org; Aguirre, Sergio
 Subject: [omap3isp RFC][PATCH 1/4] omap3isp: Abstract isp subdevs clock
 control
 
 Submodules shouldn't be aware of global register bit structure,
 specially if the submodules are shared in the future with
 other TI architectures (Davinci, future OMAPs, etc)

Oops, I just noticed a bug in this patch in clock disabling...
Will resend the updated version.

Regards,
Sergio

 
 Signed-off-by: Sergio Aguirre saagui...@ti.com
 ---
  drivers/media/video/isp/isp.c|   54
 ++
  drivers/media/video/isp/isp.h|   12 +++
  drivers/media/video/isp/ispccdc.c|6 +--
  drivers/media/video/isp/isppreview.c |6 +--
  drivers/media/video/isp/ispresizer.c |6 +--
  5 files changed, 72 insertions(+), 12 deletions(-)
 
 diff --git a/drivers/media/video/isp/isp.c b/drivers/media/video/isp/isp.c
 index 30bdc48..2e5030f 100644
 --- a/drivers/media/video/isp/isp.c
 +++ b/drivers/media/video/isp/isp.c
 @@ -991,6 +991,60 @@ void isp_sbl_disable(struct isp_device *isp, enum
 isp_sbl_resource res)
   * Clock management
   */
 
 +void isp_subclk_enable(struct isp_device *isp, enum isp_subclk_resource
 res)
 +{
 + u32 clk = 0;
 +
 + isp-subclk_resources |= res;
 +
 + if (isp-subclk_resources  OMAP3_ISP_SUBCLK_H3A)
 + clk |= ISPCTRL_H3A_CLK_EN;
 +
 + if (isp-subclk_resources  OMAP3_ISP_SUBCLK_HIST)
 + clk |= ISPCTRL_HIST_CLK_EN;
 +
 + if (isp-subclk_resources  OMAP3_ISP_SUBCLK_RESIZER)
 + clk |= ISPCTRL_RSZ_CLK_EN;
 +
 + /* NOTE: For CCDC  Preview submodules, we need to affect internal
 +  *   RAM aswell.
 +  */
 + if (isp-subclk_resources  OMAP3_ISP_SUBCLK_CCDC)
 + clk |= ISPCTRL_CCDC_CLK_EN | ISPCTRL_CCDC_RAM_EN;
 +
 + if (isp-subclk_resources  OMAP3_ISP_SUBCLK_PREVIEW)
 + clk |= ISPCTRL_PREV_CLK_EN | ISPCTRL_PREV_RAM_EN;
 +
 + isp_reg_set(isp, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL, clk);
 +}
 +
 +void isp_subclk_disable(struct isp_device *isp, enum isp_subclk_resource
 res)
 +{
 + u32 clk = 0;
 +
 + isp-subclk_resources = ~res;
 +
 + if (!(isp-subclk_resources  OMAP3_ISP_SUBCLK_H3A))
 + clk |= ISPCTRL_H3A_CLK_EN;
 +
 + if (!(isp-subclk_resources  OMAP3_ISP_SUBCLK_HIST))
 + clk |= ISPCTRL_HIST_CLK_EN;
 +
 + if (!(isp-subclk_resources  OMAP3_ISP_SUBCLK_RESIZER))
 + clk |= ISPCTRL_RSZ_CLK_EN;
 +
 + /* NOTE: For CCDC  Preview submodules, we need to affect internal
 +  *   RAM aswell.
 +  */
 + if (!(isp-subclk_resources  OMAP3_ISP_SUBCLK_CCDC))
 + clk |= ISPCTRL_CCDC_CLK_EN | ISPCTRL_CCDC_RAM_EN;
 +
 + if (!(isp-subclk_resources  OMAP3_ISP_SUBCLK_PREVIEW))
 + clk |= ISPCTRL_PREV_CLK_EN | ISPCTRL_PREV_RAM_EN;
 +
 + isp_reg_clr(isp, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL, clk);
 +}
 +
  /*
   * isp_enable_clocks - Enable ISP clocks
   * @isp: OMAP3 ISP device
 diff --git a/drivers/media/video/isp/isp.h b/drivers/media/video/isp/isp.h
 index b8f63e2..1260e9f 100644
 --- a/drivers/media/video/isp/isp.h
 +++ b/drivers/media/video/isp/isp.h
 @@ -85,6 +85,14 @@ enum isp_sbl_resource {
   OMAP3_ISP_SBL_RESIZER_WRITE = 0x200,
  };
 
 +enum isp_subclk_resource {
 + OMAP3_ISP_SUBCLK_CCDC   = 0x1,
 + OMAP3_ISP_SUBCLK_H3A= 0x2,
 + OMAP3_ISP_SUBCLK_HIST   = 0x4,
 + OMAP3_ISP_SUBCLK_PREVIEW= 0x8,
 + OMAP3_ISP_SUBCLK_RESIZER= 0x10,
 +};
 +
  enum isp_interface_type {
   ISP_INTERFACE_PARALLEL,
   ISP_INTERFACE_CSI2A_PHY2,
 @@ -262,6 +270,7 @@ struct isp_device {
   struct isp_csiphy isp_csiphy2;
 
   unsigned int sbl_resources;
 + unsigned int subclk_resources;
 
   struct iommu *iommu;
  };
 @@ -294,6 +303,9 @@ void isp_print_status(struct isp_device *isp);
  void isp_sbl_enable(struct isp_device *isp, enum isp_sbl_resource res);
  void isp_sbl_disable(struct isp_device *isp, enum isp_sbl_resource res);
 
 +void isp_subclk_enable(struct isp_device *isp, enum isp_subclk_resource
 res);
 +void isp_subclk_disable(struct isp_device *isp, enum isp_subclk_resource
 res);
 +
  int omap3isp_register_entities(struct platform_device *pdev,
  struct v4l2_device *v4l2_dev);
  void omap3isp_unregister_entities(struct platform_device *pdev);
 diff --git a/drivers/media/video/isp/ispccdc.c
 b/drivers/media/video/isp/ispccdc.c
 index c3d1d7a..4244edf 100644
 --- a/drivers/media/video/isp/ispccdc.c
 +++ b/drivers/media/video/isp/ispccdc.c
 @@ -1687,8 +1687,7 @@ static int ccdc_set_stream(struct v4l2_subdev *sd,
 int enable)
   if (enable == ISP_PIPELINE_STREAM_STOPPED)
   return 0;
 
 - isp_reg_set(isp, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL,
 - ISPCTRL_CCDC_RAM_EN

RE: [omap3isp RFC][PATCH 1/4] omap3isp: Abstract isp subdevs clock control

2010-11-19 Thread Aguirre, Sergio


 -Original Message-
 From: Aguirre, Sergio
 Sent: Friday, November 19, 2010 5:27 PM
 To: Aguirre, Sergio; Laurent Pinchart
 Cc: linux-media@vger.kernel.org
 Subject: RE: [omap3isp RFC][PATCH 1/4] omap3isp: Abstract isp subdevs
 clock control
 
 
 
  -Original Message-
  From: Aguirre, Sergio
  Sent: Friday, November 19, 2010 5:24 PM
  To: Laurent Pinchart
  Cc: linux-media@vger.kernel.org; Aguirre, Sergio
  Subject: [omap3isp RFC][PATCH 1/4] omap3isp: Abstract isp subdevs clock
  control
 
  Submodules shouldn't be aware of global register bit structure,
  specially if the submodules are shared in the future with
  other TI architectures (Davinci, future OMAPs, etc)
 
 Oops, I just noticed a bug in this patch in clock disabling...
 Will resend the updated version.

Geez, I'm apologize again. The patch was indeed correct..

Too much coffee. ;P

Regards,
Sergio

 
 Regards,
 Sergio
 
 
  Signed-off-by: Sergio Aguirre saagui...@ti.com
  ---
   drivers/media/video/isp/isp.c|   54
  ++
   drivers/media/video/isp/isp.h|   12 +++
   drivers/media/video/isp/ispccdc.c|6 +--
   drivers/media/video/isp/isppreview.c |6 +--
   drivers/media/video/isp/ispresizer.c |6 +--
   5 files changed, 72 insertions(+), 12 deletions(-)
 
  diff --git a/drivers/media/video/isp/isp.c
 b/drivers/media/video/isp/isp.c
  index 30bdc48..2e5030f 100644
  --- a/drivers/media/video/isp/isp.c
  +++ b/drivers/media/video/isp/isp.c
  @@ -991,6 +991,60 @@ void isp_sbl_disable(struct isp_device *isp, enum
  isp_sbl_resource res)
* Clock management
*/
 
  +void isp_subclk_enable(struct isp_device *isp, enum isp_subclk_resource
  res)
  +{
  +   u32 clk = 0;
  +
  +   isp-subclk_resources |= res;
  +
  +   if (isp-subclk_resources  OMAP3_ISP_SUBCLK_H3A)
  +   clk |= ISPCTRL_H3A_CLK_EN;
  +
  +   if (isp-subclk_resources  OMAP3_ISP_SUBCLK_HIST)
  +   clk |= ISPCTRL_HIST_CLK_EN;
  +
  +   if (isp-subclk_resources  OMAP3_ISP_SUBCLK_RESIZER)
  +   clk |= ISPCTRL_RSZ_CLK_EN;
  +
  +   /* NOTE: For CCDC  Preview submodules, we need to affect internal
  +*   RAM aswell.
  +*/
  +   if (isp-subclk_resources  OMAP3_ISP_SUBCLK_CCDC)
  +   clk |= ISPCTRL_CCDC_CLK_EN | ISPCTRL_CCDC_RAM_EN;
  +
  +   if (isp-subclk_resources  OMAP3_ISP_SUBCLK_PREVIEW)
  +   clk |= ISPCTRL_PREV_CLK_EN | ISPCTRL_PREV_RAM_EN;
  +
  +   isp_reg_set(isp, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL, clk);
  +}
  +
  +void isp_subclk_disable(struct isp_device *isp, enum
 isp_subclk_resource
  res)
  +{
  +   u32 clk = 0;
  +
  +   isp-subclk_resources = ~res;
  +
  +   if (!(isp-subclk_resources  OMAP3_ISP_SUBCLK_H3A))
  +   clk |= ISPCTRL_H3A_CLK_EN;
  +
  +   if (!(isp-subclk_resources  OMAP3_ISP_SUBCLK_HIST))
  +   clk |= ISPCTRL_HIST_CLK_EN;
  +
  +   if (!(isp-subclk_resources  OMAP3_ISP_SUBCLK_RESIZER))
  +   clk |= ISPCTRL_RSZ_CLK_EN;
  +
  +   /* NOTE: For CCDC  Preview submodules, we need to affect internal
  +*   RAM aswell.
  +*/
  +   if (!(isp-subclk_resources  OMAP3_ISP_SUBCLK_CCDC))
  +   clk |= ISPCTRL_CCDC_CLK_EN | ISPCTRL_CCDC_RAM_EN;
  +
  +   if (!(isp-subclk_resources  OMAP3_ISP_SUBCLK_PREVIEW))
  +   clk |= ISPCTRL_PREV_CLK_EN | ISPCTRL_PREV_RAM_EN;
  +
  +   isp_reg_clr(isp, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL, clk);
  +}
  +
   /*
* isp_enable_clocks - Enable ISP clocks
* @isp: OMAP3 ISP device
  diff --git a/drivers/media/video/isp/isp.h
 b/drivers/media/video/isp/isp.h
  index b8f63e2..1260e9f 100644
  --- a/drivers/media/video/isp/isp.h
  +++ b/drivers/media/video/isp/isp.h
  @@ -85,6 +85,14 @@ enum isp_sbl_resource {
  OMAP3_ISP_SBL_RESIZER_WRITE = 0x200,
   };
 
  +enum isp_subclk_resource {
  +   OMAP3_ISP_SUBCLK_CCDC   = 0x1,
  +   OMAP3_ISP_SUBCLK_H3A= 0x2,
  +   OMAP3_ISP_SUBCLK_HIST   = 0x4,
  +   OMAP3_ISP_SUBCLK_PREVIEW= 0x8,
  +   OMAP3_ISP_SUBCLK_RESIZER= 0x10,
  +};
  +
   enum isp_interface_type {
  ISP_INTERFACE_PARALLEL,
  ISP_INTERFACE_CSI2A_PHY2,
  @@ -262,6 +270,7 @@ struct isp_device {
  struct isp_csiphy isp_csiphy2;
 
  unsigned int sbl_resources;
  +   unsigned int subclk_resources;
 
  struct iommu *iommu;
   };
  @@ -294,6 +303,9 @@ void isp_print_status(struct isp_device *isp);
   void isp_sbl_enable(struct isp_device *isp, enum isp_sbl_resource res);
   void isp_sbl_disable(struct isp_device *isp, enum isp_sbl_resource
 res);
 
  +void isp_subclk_enable(struct isp_device *isp, enum isp_subclk_resource
  res);
  +void isp_subclk_disable(struct isp_device *isp, enum
 isp_subclk_resource
  res);
  +
   int omap3isp_register_entities(struct platform_device *pdev,
 struct v4l2_device *v4l2_dev);
   void omap3isp_unregister_entities(struct platform_device *pdev);
  diff --git a/drivers/media/video/isp/ispccdc.c
  b/drivers/media/video/isp/ispccdc.c

RE: [omap3isp][PATCH v2 0/9] YUV support for CCDC + cleanups

2010-11-16 Thread Aguirre, Sergio


 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Tuesday, November 16, 2010 5:45 AM
 To: Aguirre, Sergio
 Cc: linux-media@vger.kernel.org
 Subject: Re: [omap3isp][PATCH v2 0/9] YUV support for CCDC + cleanups
 
 Hi Sergio,

Hi Laurent,

 
 Thanks for the patches.

You're welcome.

 
 I've reviewed and tested them and found no issue. They will be a small
 delay
 as I need to sync our internal tree with the public tree before applying
 them.

Not a problem.

Thanks for your time.

Regards,
Sergio

 
 --
 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: [omap3isp RFC][PATCH 02/10] omap3isp: ccdc: Write SYN_MODE.INPMOD based on fmt

2010-11-15 Thread Aguirre, Sergio
Hi Laurent,

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Monday, November 15, 2010 4:37 AM
 To: Aguirre, Sergio
 Cc: linux-media@vger.kernel.org
 Subject: Re: [omap3isp RFC][PATCH 02/10] omap3isp: ccdc: Write
 SYN_MODE.INPMOD based on fmt
 
 Hi Sergio,
 
 Thanks for the patch.

Thanks for reviewing.

 
 On Friday 12 November 2010 22:18:05 Sergio Aguirre wrote:
  This takes into account the input format to select the
  adequate configuration for SYNC mode.
 
  Also, change bitmask ISPCCDC_SYN_MODE_INPMOD_MASK to be
  more consistent with other bitmasks.
 
 Could you please squash this with the previous patch ?

Sure. I will resend the updated patchset in a couple of minutes.

Regards,
Sergio

 
 --
 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: [RFC/PATCH v2 5/6] omap3: Export omap3isp platform device structure

2010-10-05 Thread Aguirre, Sergio
Hi Laurent,

 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
 Sent: Tuesday, October 05, 2010 8:19 AM
 To: linux-media@vger.kernel.org
 Cc: sakari.ai...@maxwell.research.nokia.com
 Subject: [RFC/PATCH v2 5/6] omap3: Export omap3isp platform device
 structure
 
 From: Stanimir Varbanov svarba...@mm-sol.com
 
 The omap3isp platform device requires platform data. As the data can be
 provided by a kernel module, the device can't be registered during arch
 initialization.
 
 Remove the omap3isp platform device registration from
 omap_init_camera(), and export the platform device structure to let
 board code register/unregister it.
 

This patch needs to go through linux-omap ML.

Regards,
Sergio

 Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  arch/arm/mach-omap2/devices.c |   18 --
  arch/arm/mach-omap2/devices.h |   17 +
  2 files changed, 33 insertions(+), 2 deletions(-)
  create mode 100644 arch/arm/mach-omap2/devices.h
 
 diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
 index ade8db0..f9bc507 100644
 --- a/arch/arm/mach-omap2/devices.c
 +++ b/arch/arm/mach-omap2/devices.c
 @@ -31,6 +31,8 @@
 
  #include mux.h
 
 +#include devices.h
 +
  #if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
 
  static struct resource cam_resources[] = {
 @@ -141,16 +143,28 @@ static struct resource omap3isp_resources[] = {
   }
  };
 
 -static struct platform_device omap3isp_device = {
 +static void omap3isp_release(struct device *dev)
 +{
 + /* Zero the device structure to avoid re-initialization complaints
 from
 +  * kobject when the device will be re-registered.
 +  */
 + memset(dev, 0, sizeof(*dev));
 + dev-release = omap3isp_release;
 +}
 +
 +struct platform_device omap3isp_device = {
   .name   = omap3isp,
   .id = -1,
   .num_resources  = ARRAY_SIZE(omap3isp_resources),
   .resource   = omap3isp_resources,
 + .dev = {
 + .release= omap3isp_release,
 + },
  };
 +EXPORT_SYMBOL_GPL(omap3isp_device);
 
  static inline void omap_init_camera(void)
  {
 - platform_device_register(omap3isp_device);
  }
  #else
  static inline void omap_init_camera(void)
 diff --git a/arch/arm/mach-omap2/devices.h b/arch/arm/mach-omap2/devices.h
 new file mode 100644
 index 000..f312d49
 --- /dev/null
 +++ b/arch/arm/mach-omap2/devices.h
 @@ -0,0 +1,17 @@
 +/*
 + * arch/arm/mach-omap2/devices.h
 + *
 + * OMAP2 platform device setup/initialization
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + */
 +
 +#ifndef __ARCH_ARM_MACH_OMAP_DEVICES_H
 +#define __ARCH_ARM_MACH_OMAP_DEVICES_H
 +
 +extern struct platform_device omap3isp_device;
 +
 +#endif
 --
 1.7.2.2
 
 --
 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
--
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


[Query] Is there a spec to request video sensor information?

2010-09-09 Thread Aguirre, Sergio
Hi,

I was wondering if there exists a current standard way to query a
Imaging sensor driver for knowing things like the signal vert/horz blanking 
time.

In an old TI custom driver, we used to have a private IOCTL in the sensor
Driver we interfaced with the omap3 ISP, which was basically reporting:

- Active resolution (Actual image size)
- Full resolution (Above size + dummy pixel columns/rows representing blanking 
times)

However I resist to keep importing that custom interface, since I think its
Something that could be already part of an standard API.

Any pointers will be much appreciated.

Regards,
Sergio

--
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


[Query][videobuf-dma-sg] Pages in Highmem handling

2010-08-27 Thread Aguirre, Sergio
Hi,

I see that in current videobuf library, for DMA SG code, these functions fail 
when
Detecting a page in Highmem region:

- videobuf_pages_to_sg
- videobuf_vmalloc_to_sg

Now, what's the real reason to not allow handling of Highmem pages?
Is it an assumption that _always_ HighMem is not reachable by DMA?

I guess my point is, OMAP platform (and maybe other platforms) can handle
Highmem pages without any problem. I commented these validations:

65 static struct scatterlist *videobuf_vmalloc_to_sg(unsigned char *virt,
66   int nr_pages)
67 {

...

77 for (i = 0; i  nr_pages; i++, virt += PAGE_SIZE) {
78 pg = vmalloc_to_page(virt);
79 if (NULL == pg)
80 goto err;
81 /* BUG_ON(PageHighMem(pg)); */

...

96 static struct scatterlist *videobuf_pages_to_sg(struct page **pages,
97 int nr_pages, int offset)
98 {

...

109 /* if (PageHighMem(pages[0])) */
110 /* DMA to highmem pages might not work */
111 /* goto highmem; */
112 sg_set_page(sglist[0], pages[0], PAGE_SIZE - offset, offset);
113 for (i = 1; i  nr_pages; i++) {
114 if (NULL == pages[i])
115 goto nopage;
116 /* if (PageHighMem(pages[i]))
117 goto highmem; */
118 sg_set_page(sglist[i], pages[i], PAGE_SIZE, 0);
119 }

Can somebody shed any light on this?

Regards,
Sergio
--
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: [omap3camera] How does a lens subdevice get powered up?

2010-08-26 Thread Aguirre, Sergio
Hi Laurent,

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Thursday, August 26, 2010 2:31 AM
 To: Aguirre, Sergio
 Cc: linux-media@vger.kernel.org; Nataraju, Kiran
 Subject: Re: [omap3camera] How does a lens subdevice get powered up?
 
 Hi Sergio,
 
 On Wednesday 25 August 2010 22:15:36 Aguirre, Sergio wrote:
  Hi Laurent,
 
  I see that usually a sensor is powered up on attempting a
 VIDIOC_STREAMON
  at the capture endpoint of the pipeline, in which the sensor is linked.
 
  Now, what I don't understand quite well is, the Lens driver is a
 separate
  subdevice, BUT it's obviously not linked to the sensor, nor the
 pipeline.
 
  How would the lens driver know when to power up?
 
 At the moment a userspace application needs to keep the lens subdev open
 to
 power-up the lens controller.

I see... So in that case, does it make sense to consider it as a media entity?

I mean, there's no link, nor pad operations involved, so it doesn't really
add any value...

What do you think?

Regards,
Sergio

 
 --
 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: [omap3camera] How does a lens subdevice get powered up?

2010-08-26 Thread Aguirre, Sergio
Hi Laurent,

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Thursday, August 26, 2010 10:04 AM
 To: Aguirre, Sergio
 Cc: linux-media@vger.kernel.org; Nataraju, Kiran
 Subject: Re: [omap3camera] How does a lens subdevice get powered up?
 
 Hi Sergio,
 
 On Thursday 26 August 2010 16:54:37 Aguirre, Sergio wrote:
  On Thursday, August 26, 2010 2:31 AM Laurent Pinchart wrote:
   On Wednesday 25 August 2010 22:15:36 Aguirre, Sergio wrote:
   
I see that usually a sensor is powered up on attempting a
VIDIOC_STREAMON at the capture endpoint of the pipeline, in which
 the
sensor is linked.
   
Now, what I don't understand quite well is, the Lens driver is a
separate subdevice, BUT it's obviously not linked to the sensor, nor
 the
pipeline.
   
How would the lens driver know when to power up?
  
   At the moment a userspace application needs to keep the lens subdev
 open
   to power-up the lens controller.
 
  I see... So in that case, does it make sense to consider it as a media
  entity?
 
  I mean, there's no link, nor pad operations involved, so it doesn't
 really
  add any value...
 
  What do you think?
 
 Even if not part of the image pipeline, the lens controller is still part
 of
 the media device. I think it makes sense to expose it as an entity and a
 V4L2
 subdevice.

Hmm... I don't know what I was thinking... you're right. :)

Now that I rethink what I just said vs your answer, I think you have a point, 
so I'll drop that thought...

However, I think still there's something that could be done here...

Imagine a scenario in which you have 2 sensors, each one with a different
Coil motor driver to control each sensor's lens position.

Should we have a way to register some sort of association between
Sensor and lens subdevices? That way, by querying the media device, an app
can know which lens is associated with what sensor, without any hardcoding.

That would be very similar to the case in which you would want to associate
an audio capturing subdev with a video capturing subdev. They are not 
technically sharing the same data, but they are related.

Is this kind of association considered in the Media Controller framework
implementation currently?

Regards,
Sergio

 
 --
 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: [omap3camera] How does a lens subdevice get powered up?

2010-08-26 Thread Aguirre, Sergio
Hi Laurent,

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Thursday, August 26, 2010 10:36 AM
 To: Aguirre, Sergio
 Cc: linux-media@vger.kernel.org; Nataraju, Kiran
 Subject: Re: [omap3camera] How does a lens subdevice get powered up?
 
 Hi Sergio,
 
 On Thursday 26 August 2010 17:33:28 Aguirre, Sergio wrote:
  On Thursday, August 26, 2010 10:04 AM Laurent Pinchart wrote:
  
   Even if not part of the image pipeline, the lens controller is still
 part
   of the media device. I think it makes sense to expose it as an entity
 and
   a V4L2 subdevice.
 
  Hmm... I don't know what I was thinking... you're right. :)
 
  Now that I rethink what I just said vs your answer, I think you have a
  point, so I'll drop that thought...
 
  However, I think still there's something that could be done here...
 
  Imagine a scenario in which you have 2 sensors, each one with a
 different
  Coil motor driver to control each sensor's lens position.
 
  Should we have a way to register some sort of association between
  Sensor and lens subdevices? That way, by querying the media device, an
 app
  can know which lens is associated with what sensor, without any
 hardcoding.
 
  That would be very similar to the case in which you would want to
 associate
  an audio capturing subdev with a video capturing subdev. They are not
  technically sharing the same data, but they are related.
 
  Is this kind of association considered in the Media Controller framework
  implementation currently?
 
 It's implemented in the latest media controller RFC :-)
 
 Entities now have a group ID that the driver can set to report
 associations
 such as sensor-coil-flash or video-audio.

Oh ok, I see.

Perfect!

Thanks for clarifying that.

Regards,
Sergio

 
 --
 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


[RESEND][omap3camera] How does a lens subdevice get powered up?

2010-08-25 Thread Aguirre, Sergio
(Resending as plain text, as I sent it originally as HTML and
got rejected by ML security policies)

Hi Laurent,

I see that usually a sensor is powered up on attempting a
VIDIOC_STREAMON at the capture endpoint of the pipeline,
in which the sensor is linked.

Now, what I don't understand quite well is, the Lens driver
is a separate subdevice, BUT it's obviously not linked to the
sensor, nor the pipeline.

How would the lens driver know when to power up?

Regards,
Sergio
--
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: [RFC/PATCH v3 00/10] Media controller (core and V4L2)

2010-08-19 Thread Aguirre, Sergio
Hi Laurent,

 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
 Sent: Thursday, July 29, 2010 11:07 AM
 To: linux-media@vger.kernel.org
 Cc: sakari.ai...@maxwell.research.nokia.com
 Subject: [RFC/PATCH v3 00/10] Media controller (core and V4L2)
 
 Hi everybody,
 
 Here's the third version of the media controller patches. All comments
 received
 on the first and second versions have (hopefully) been incorporated.
 
 The rebased V4L2 API additions and OMAP3 ISP patches will follow. Once
 again
 please consider them as sample code only.
 
 Laurent Pinchart (8):
   media: Media device node support
   media: Media device
   media: Entities, pads and links
   media: Entities, pads and links enumeration
   media: Links setup
   v4l: Add a media_device pointer to the v4l2_device structure
   v4l: Make video_device inherit from media_entity
   v4l: Make v4l2_subdev inherit from media_entity

This patch (#0010) doesn't apply to mainline, after this commit:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b74c0aac357e5c71ee6de98b9887fe478bc73cf4

Am I missing something here?

Regards,
Sergio

 
 Sakari Ailus (2):
   media: Entity graph traversal
   media: Reference count and power handling
 
  Documentation/media-framework.txt|  481 
  Documentation/video4linux/v4l2-framework.txt |   71 +++-
  drivers/media/Makefile   |8 +-
  drivers/media/media-device.c |  327 ++
  drivers/media/media-devnode.c|  326 ++
  drivers/media/media-entity.c |  613
 ++
  drivers/media/video/v4l2-dev.c   |   35 ++-
  drivers/media/video/v4l2-device.c|   45 ++-
  drivers/media/video/v4l2-subdev.c|   27 ++-
  include/linux/media.h|   78 
  include/media/media-device.h |   70 +++
  include/media/media-devnode.h|   84 
  include/media/media-entity.h |  107 +
  include/media/v4l2-dev.h |6 +
  include/media/v4l2-device.h  |2 +
  include/media/v4l2-subdev.h  |7 +
  16 files changed, 2265 insertions(+), 22 deletions(-)
  create mode 100644 Documentation/media-framework.txt
  create mode 100644 drivers/media/media-device.c
  create mode 100644 drivers/media/media-devnode.c
  create mode 100644 drivers/media/media-entity.c
  create mode 100644 include/linux/media.h
  create mode 100644 include/media/media-device.h
  create mode 100644 include/media/media-devnode.h
  create mode 100644 include/media/media-entity.h
 
 --
 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
--
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: [RFC/PATCH v3 00/10] Media controller (core and V4L2)

2010-08-19 Thread Aguirre, Sergio

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Thursday, August 19, 2010 2:12 PM
 To: Aguirre, Sergio
 Cc: linux-media@vger.kernel.org; sakari.ai...@maxwell.research.nokia.com
 Subject: Re: [RFC/PATCH v3 00/10] Media controller (core and V4L2)
 
 Hi Sergio,
 
 On Thursday 19 August 2010 21:09:30 Aguirre, Sergio wrote:
   -Original Message-
   From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
   ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
   Sent: Thursday, July 29, 2010 11:07 AM
   To: linux-media@vger.kernel.org
   Cc: sakari.ai...@maxwell.research.nokia.com
   Subject: [RFC/PATCH v3 00/10] Media controller (core and V4L2)
  
   Hi everybody,
  
   Here's the third version of the media controller patches. All comments
   received on the first and second versions have (hopefully) been
   incorporated.
  
   The rebased V4L2 API additions and OMAP3 ISP patches will follow. Once
   again please consider them as sample code only.
  
   Laurent Pinchart (8):
 media: Media device node support
 media: Media device
 media: Entities, pads and links
 media: Entities, pads and links enumeration
 media: Links setup
 v4l: Add a media_device pointer to the v4l2_device structure
 v4l: Make video_device inherit from media_entity
 v4l: Make v4l2_subdev inherit from media_entity
 
  This patch (#0010) doesn't apply to mainline, after this commit:
 
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-
 2.6.git;a=commit;h
  =b74c0aac357e5c71ee6de98b9887fe478bc73cf4
 
  Am I missing something here?
 
 Yes, you're missing the next version of the patches :-) I'll probably send
 them tomorrow.

Ohh ok, :)

Thanks!

Regards,
Sergio

 
 --
 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: [PATCH] Fixes field names that changed

2010-08-18 Thread Aguirre, Sergio
Hi Henrique,

Just some minor comments about the patch description below:

 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Henrique Camargo
 Sent: Tuesday, August 17, 2010 9:35 AM
 To: Mauro Carvalho Chehab
 Cc: Guennadi Liakhovetski; Karicheri, Muralidharan; linux-
 me...@vger.kernel.org; linux-ker...@vger.kernel.org
 Subject: [PATCH] Fixes field names that changed

Add missing subject prefix to quickly describe the affected driver:

Subject: [PATCH] mt9t032: Fixes field names that changed

 
 If CONFIG_VIDEO_ADV_DEBUG was set, the driver failed to compile because
 the fields get_register and set_register changed names to s_register and
 s_register in the struct v4l2_subdev_core_ops.

Please break down this comment to 70 chars max.

Also, you said s_register twice.

Regards,
Sergio

 
 Signed-off-by: Henrique Camargo henri...@henriquecamargo.com
 ---
  drivers/media/video/mt9t031.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
 index 716fea6..f3d1995 100644
 --- a/drivers/media/video/mt9t031.c
 +++ b/drivers/media/video/mt9t031.c
 @@ -499,8 +499,8 @@ static const struct v4l2_subdev_core_ops
 mt9t031_core_ops = {
   .g_ctrl = mt9t031_get_control,
   .s_ctrl = mt9t031_set_control,
  #ifdef CONFIG_VIDEO_ADV_DEBUG
 - .get_register = mt9t031_get_register,
 - .set_register = mt9t031_set_register,
 + .g_register = mt9t031_get_register,
 + .s_register = mt9t031_set_register,
  #endif
  };
 
 --
 1.7.0.4
 
 
 
 --
 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
--
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: [PATCH] Fixes field names that changed

2010-08-18 Thread Aguirre, Sergio
Oops, fixing my own typo below:

 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio
 Sent: Wednesday, August 18, 2010 7:16 PM
 To: henri...@henriquecamargo.com; Mauro Carvalho Chehab
 Cc: Guennadi Liakhovetski; Karicheri, Muralidharan; linux-
 me...@vger.kernel.org; linux-ker...@vger.kernel.org
 Subject: RE: [PATCH] Fixes field names that changed
 
 Hi Henrique,
 
 Just some minor comments about the patch description below:
 
  -Original Message-
  From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
  ow...@vger.kernel.org] On Behalf Of Henrique Camargo
  Sent: Tuesday, August 17, 2010 9:35 AM
  To: Mauro Carvalho Chehab
  Cc: Guennadi Liakhovetski; Karicheri, Muralidharan; linux-
  me...@vger.kernel.org; linux-ker...@vger.kernel.org
  Subject: [PATCH] Fixes field names that changed
 
 Add missing subject prefix to quickly describe the affected driver:
 
 Subject: [PATCH] mt9t032: Fixes field names that changed

mt9t032 - mt9t031.

Sorry...

Regards,
Sergio
 
 
  If CONFIG_VIDEO_ADV_DEBUG was set, the driver failed to compile because
  the fields get_register and set_register changed names to s_register and
  s_register in the struct v4l2_subdev_core_ops.
 
 Please break down this comment to 70 chars max.
 
 Also, you said s_register twice.
 
 Regards,
 Sergio
 
 
  Signed-off-by: Henrique Camargo henri...@henriquecamargo.com
  ---
   drivers/media/video/mt9t031.c |4 ++--
   1 files changed, 2 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/media/video/mt9t031.c
 b/drivers/media/video/mt9t031.c
  index 716fea6..f3d1995 100644
  --- a/drivers/media/video/mt9t031.c
  +++ b/drivers/media/video/mt9t031.c
  @@ -499,8 +499,8 @@ static const struct v4l2_subdev_core_ops
  mt9t031_core_ops = {
  .g_ctrl = mt9t031_get_control,
  .s_ctrl = mt9t031_set_control,
   #ifdef CONFIG_VIDEO_ADV_DEBUG
  -   .get_register = mt9t031_get_register,
  -   .set_register = mt9t031_set_register,
  +   .g_register = mt9t031_get_register,
  +   .s_register = mt9t031_set_register,
   #endif
   };
 
  --
  1.7.0.4
 
 
 
  --
  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
 --
 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
--
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


[ANNOUNCE] OMAP3 Camera ISP driver wiki in omappedia.org

2010-08-13 Thread Aguirre, Sergio
Hi all,

I'll like to announce a new wikipage entry in http://omappedia.org site for
OMAP3 Camera-ISP progress and details. Please find it here.

http://omappedia.org/wiki/Camera-ISP_Driver

The intention is to provide an online documentation of the work and progress
of the patches submission, and its dependencies (Media Controller Framework,
specifically).

If you're interested to contribute/experiment with the driver, this is intended 
to
be a good start point for that, and also feel free to update it aswell.

The more people trying the driver, the better, so we can have as much platforms
running with it as possible, and we can claim that the driver is flexible enough
for all.

Have a great weekend!

Regards,
Sergio
--
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: [media-ctl PATCH 2/3] Just include kernel headers

2010-07-30 Thread Aguirre, Sergio
Hi Laurent,

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Friday, July 30, 2010 9:24 AM
 To: Aguirre, Sergio
 Cc: linux-media@vger.kernel.org
 Subject: Re: [media-ctl PATCH 2/3] Just include kernel headers
 
 Hi Sergio,
 
 On Friday 30 July 2010 16:10:08 Aguirre, Sergio wrote:
  On Friday 30 July 2010 8:45 AM Laurent Pinchart wrote:
   On Wednesday 14 July 2010 18:17:25 Sergio Aguirre wrote:
We shouldn't require full kernel source for this.
  
   That's right in theory, but I then get
  
   $ make KDIR=/home/laurent/src/arm/kernel/
   arm-none-linux-gnueabi-gcc -O2 -Wall -fpic -I. -
   I/home/laurent/src/arm/kernel//include-c -o media.o media.c
   In file included from /opt/cs/arm-2009q1/bin/../arm-none-linux-
   gnueabi/libc/usr/include/asm/types.h:4,
from
   /home/laurent/src/arm/kernel//include/linux/types.h:4,
from
   /home/laurent/src/arm/kernel//include/linux/videodev2.h:66,
from media.c:31:
   /home/laurent/src/arm/kernel//include/asm-generic/int-ll64.h:11:29:
   error: asm/bitsperlong.h: No such file or directory
   make: *** [media.o] Error 1
  
   when building against a kernel tree.
 
  KDIR doesn't exist anymore.
 
  By the result of your log, I don't see how that value got passed into
 the
  makefile... Are you sure you applied the patch correctly?
 
 I haven't, I've just removed the arch include dir from KDIR in the
 Makefile.
 The end result is the same.

Hmm..

I think this is expected, since the kernel headers folder generated with

make ARCH=arm INSTALL_HDR_PATH=your-fs-root headers_install

Is not the same as just reading the kernel source include folder.

Some #ifdef get resolved depending on the arch, and the headers are
rebuilt. See : Documentation/make/headers_install.txt

So, I guess it's not as simple as just removing the arch include folder.

Regards,
Sergio

 
 --
 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: [media-ctl PATCH 2/3] Just include kernel headers

2010-07-30 Thread Aguirre, Sergio
Hi Laurent,

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Friday, July 30, 2010 10:40 AM
 To: Aguirre, Sergio
 Cc: linux-media@vger.kernel.org
 Subject: Re: [media-ctl PATCH 2/3] Just include kernel headers
 
 Hi Sergio,

snip

 
 Ideally the application should be built against installed kernel headers,
 bug
 given the early stage of development of the media controller, I expect
 most
 people to build it against a kernel tree. I would like to keep the
 Makefile
 as-is for now, and change it when the media controller patches will reach
 the
 mainline kernel.

Ok, understood. Not a problem.

Regards,
Sergio

 
 --
 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: [media-ctl] [omap3camera:devel] How to use the app?

2010-07-21 Thread Aguirre, Sergio
Hi Laurent,

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Tuesday, June 29, 2010 5:23 AM
 To: Aguirre, Sergio
 Cc: Sakari Ailus; linux-media@vger.kernel.org
 Subject: Re: [media-ctl] [omap3camera:devel] How to use the app?
 

snip

 
 You will find a set of patches that remove the legacy video nodes attached
 to
 this e-mail. They haven't been applied to the omap3camera tree yet, as we
 still haven't fixed all userspace components yet, but they should get
 there in
 a few weeks hopefully. You should probably apply them to your tree to make
 sure you don't start using the legacy video nodes by mistake. They also
 remove
 a lot of code, which is always good, and remove the hardcoded number of
 sensors.

By any chance, do you keep rebasing these patches in a branch somewhere?

I tried rebasing them against latest 'devel' branch, but they fail on
omap34xxcam.c, because the removed content is not the same. The delta is
just an addition you did to reset all non-legacy links during init.

Is it ok to still remove this completely? Or is this going to be rellocated
somewhere?

The patch I'm talking about is named: omap34xxcam: Reset all links before 
setting up the pipeline.

Regards,
Sergio

 
 --
 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: [RFC/PATCH 02/10] media: Media device

2010-07-16 Thread Aguirre, Sergio
Hi Laurent,

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Friday, July 16, 2010 3:56 AM
 To: Aguirre, Sergio
 Cc: linux-media@vger.kernel.org; sakari.ai...@maxwell.research.nokia.com
 Subject: Re: [RFC/PATCH 02/10] media: Media device
 
 Hi Sergio,
 
 On Thursday 15 July 2010 16:22:06 Aguirre, Sergio wrote:
   On Wednesday 14 July 2010 08:30:00 Laurent Pinchart wrote:
 
 snip
 
   diff --git a/drivers/media/media-device.c b/drivers/media/media-
 device.c
   new file mode 100644
   index 000..a4d3db5
   --- /dev/null
   +++ b/drivers/media/media-device.c
   @@ -0,0 +1,77 @@
 
 snip
 
   +/**
   + * media_device_register - register a media device
   + * @mdev:The media device
   + *
   + * The caller is responsible for initializing the media device before
   + * registration. The following fields must be set:
   + *
   + * - dev should point to the parent device. The field can be NULL
 when no
   + *   parent device is available (for instance with ISA devices).
   + * - name should be set to the device name. If the name is empty a
 parent
   + *   device must be set. In that case the name will be set to the
 parent
   + *   device driver name followed by a space and the parent device
 name.
   + */
   +int __must_check media_device_register(struct media_device *mdev)
   +{
   + /* If dev == NULL, then name must be filled in by the caller */
   + if (mdev-dev == NULL  WARN_ON(!mdev-name[0]))
 
  If mdev == NULL, you'll have a kernel panic here.
 
 That's why drivers must not call media_device_register with a NULL pointer
 :-)
 It's not a valid use case, unlike kfree(NULL) for instance.

Right. I know.

I guess I was thinking more in terms of not compromising the system because
of a buggy driver, and exit gracefully instead... But I guess it's also ok,
as a driver developer is usually updating the full kernel anyways.

Regards,
Sergio

 
 --
 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: [RFC/PATCH 03/10] media: Entities, pads and links

2010-07-16 Thread Aguirre, Sergio
Hi Laurent,

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Friday, July 16, 2010 4:10 AM
 To: Aguirre, Sergio
 Cc: linux-media@vger.kernel.org; sakari.ai...@maxwell.research.nokia.com
 Subject: Re: [RFC/PATCH 03/10] media: Entities, pads and links
 
 Hi Sergio,
 
 Thanks for the review.
 
 On Thursday 15 July 2010 16:35:20 Aguirre, Sergio wrote:
  On Wednesday 14 July 2010 08:30:00 Laurent Pinchart wrote:
 
 [snip]
 
   diff --git a/drivers/media/media-device.c b/drivers/media/media-
 device.c
   index a4d3db5..6361367 100644
   --- a/drivers/media/media-device.c
   +++ b/drivers/media/media-device.c
 
 [snip]
 
   @@ -72,6 +77,54 @@ EXPORT_SYMBOL_GPL(media_device_register);
 
 [snip]
 
   +
   +/**
   + * media_device_register_entity - Register an entity with a media
 device
   + * @mdev:The media device
   + * @entity:  The entity
   + */
   +int __must_check media_device_register_entity(struct media_device
 *mdev,
   +   struct media_entity
 *entity)
   +{
 
  What if mdev == NULL OR entity == NULL?
 
 It's not a valid use case. Drivers must not try to register a NULL entity,
 or
 an entity to a NULL media device.

Ok.

 
   + /* Warn if we apparently re-register an entity */
   + WARN_ON(entity-parent != NULL);
 
  Shouldn't we exit with -EBUSY here instead? Or is there a usecase
  In which this is a valid scenario?
 
 entity-parent != NULL isn't a valid scenario. It's a driver bug, and
 WARN_ON
 will result in a backtrace being printed, notifying the driver developer
 that
 something is seriously wrong.

Ok.

 
   + entity-parent = mdev;
   +
   + spin_lock(mdev-lock);
   + entity-id = mdev-entity_id++;
   + list_add_tail(entity-list, mdev-entities);
   + spin_unlock(mdev-lock);
   +
   + return 0;
   +}
   +EXPORT_SYMBOL_GPL(media_device_register_entity);
   +
   +/**
   + * media_device_unregister_entity - Unregister an entity
   + * @entity:  The entity
   + *
   + * If the entity has never been registered this function will return
   + * immediately.
   + */
   +void media_device_unregister_entity(struct media_entity *entity)
   +{
   + struct media_device *mdev = entity-parent;
 
  What if entity == NULL?
 
 Still not a valid use case, don't unregister NULL.

Ok.

 
   +
   + if (mdev == NULL)
   + return;
   +
   + spin_lock(mdev-lock);
   + list_del(entity-list);
   + spin_unlock(mdev-lock);
   + entity-parent = NULL;
   +}
   +EXPORT_SYMBOL_GPL(media_device_unregister_entity);
   diff --git a/drivers/media/media-entity.c b/drivers/media/media-
 entity.c
   new file mode 100644
   index 000..d5a4b4c
   --- /dev/null
   +++ b/drivers/media/media-entity.c
   @@ -0,0 +1,145 @@
   +/*
   + *  Media Entity support
   + *
   + *  Copyright (C) 2009 Laurent Pinchart
   laurent.pinch...@ideasonboard.com
 
  2010?
 
 Oops, yes, will fix.
 
 [snip]
 
   +int
   +media_entity_create_link(struct media_entity *source, u8 source_pad,
   +  struct media_entity *sink, u8 sink_pad, u32
 flags)
   +{
   + struct media_entity_link *link;
   + struct media_entity_link *backlink;
   +
   + BUG_ON(source == NULL || sink == NULL);
   + BUG_ON(source_pad = source-num_pads);
   + BUG_ON(sink_pad = sink-num_pads);
 
  Isn't this too dramatic? :)
 
  I mean, does the entire system needs to be halted because you won't be
  able to link your video subdevices?
 
 If source or sink is NULL, the second or third BUG_ON will result in a
 crash.
 If the source or sink pad numbers are out of bounds, undefined memory will
 be
 dereferenced later. Both conditions will likely result in a crash, so it's
 better to have a predictable, easy to understand crash.
 
 Once again this should never happen. It's a driver bug if it does, and
 should
 not happen randomly at runtime.

Ok.

 
 [snip]
 
   diff --git a/include/media/media-entity.h b/include/media/media-
 entity.h
   new file mode 100644
   index 000..0929a90
   --- /dev/null
   +++ b/include/media/media-entity.h
   @@ -0,0 +1,79 @@
   +#ifndef _MEDIA_ENTITY_H
   +#define _MEDIA_ENTITY_H
   +
   +#include linux/list.h
   +
   +#define MEDIA_ENTITY_TYPE_NODE   1
   +#define MEDIA_ENTITY_TYPE_SUBDEV 2
   +
   +#define MEDIA_NODE_TYPE_V4L  1
   +#define MEDIA_NODE_TYPE_FB   2
   +#define MEDIA_NODE_TYPE_ALSA 3
   +#define MEDIA_NODE_TYPE_DVB  4
   +
   +#define MEDIA_SUBDEV_TYPE_VID_DECODER1
   +#define MEDIA_SUBDEV_TYPE_VID_ENCODER2
   +#define MEDIA_SUBDEV_TYPE_MISC   3
   +
   +#define MEDIA_LINK_FLAG_ACTIVE   (1  0)
   +#define MEDIA_LINK_FLAG_IMMUTABLE(1  1)
   +
   +#define MEDIA_PAD_TYPE_INPUT 1
   +#define MEDIA_PAD_TYPE_OUTPUT2
 
  Shouldn't all the above be enums? (except of course the
  MEDIA_LINK_FLAG_* defines)
 
 They can be enums

RE: [RFC/PATCH 02/10] media: Media device

2010-07-16 Thread Aguirre, Sergio


 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Friday, July 16, 2010 3:53 AM
 To: Aguirre, Sergio
 Cc: linux-media@vger.kernel.org; sakari.ai...@maxwell.research.nokia.com
 Subject: Re: [RFC/PATCH 02/10] media: Media device
 
 Hi Sergio,
 
 Thanks for the review.
 
 On Thursday 15 July 2010 16:16:44 Aguirre, Sergio wrote:
   On Wednesday 14 July 2010 08:30:00 Laurent Pinchart wrote:
 
 snip
 
   diff --git a/include/media/media-device.h b/include/media/media-
 device.h
   new file mode 100644
   index 000..6c1fc4a
   --- /dev/null
   +++ b/include/media/media-device.h
   @@ -0,0 +1,53 @@
 
 [snip]
 
   +#ifndef _MEDIA_DEVICE_H
   +#define _MEDIA_DEVICE_H
   +
   +#include linux/device.h
   +#include linux/list.h
   +
   +#include media/media-devnode.h
   +
   +/* Each instance of a media device should create the media_device
 struct,
   + * either stand-alone or embedded in a larger struct.
   + *
   + * It allows easy access to sub-devices (see v4l2-subdev.h) and
 provides
   + * basic media device-level support.
   + */
   +
   +#define MEDIA_DEVICE_NAME_SIZE (20 + 16)
 
  Where does above numbers come from ??
 
 Copied from v4l2-device.h. It was originally BUS_ID_SIZE (the constant is
 now
 gone) + 16.
 
 I can replace that by a hardcoded 32.

Ok.

Regards,
Sergio
 
 --
 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: [RFC/PATCH 02/10] media: Media device

2010-07-15 Thread Aguirre, Sergio
Hi Laurent,

Very minor comment below.

 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
 Sent: Wednesday, July 14, 2010 8:30 AM
 To: linux-media@vger.kernel.org
 Cc: sakari.ai...@maxwell.research.nokia.com
 Subject: [RFC/PATCH 02/10] media: Media device
 
 The media_device structure abstracts functions common to all kind of
 media devices (v4l2, dvb, alsa, ...). It manages media entities and
 offers a userspace API to discover and configure the media device
 internal topology.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  Documentation/media-framework.txt |   68 
  drivers/media/Makefile|2 +-
  drivers/media/media-device.c  |   77
 +
  include/media/media-device.h  |   53 +
  4 files changed, 199 insertions(+), 1 deletions(-)
  create mode 100644 Documentation/media-framework.txt
  create mode 100644 drivers/media/media-device.c
  create mode 100644 include/media/media-device.h


snip

 diff --git a/include/media/media-device.h b/include/media/media-device.h
 new file mode 100644
 index 000..6c1fc4a
 --- /dev/null
 +++ b/include/media/media-device.h
 @@ -0,0 +1,53 @@
 +/*
 + *  Media device support header.
 + *
 + *  Copyright (C) 2010  Laurent Pinchart
 laurent.pinch...@ideasonboard.com
 + *
 + *  This program is free software; you can redistribute it and/or modify
 + *  it under the terms of the GNU General Public License as published by
 + *  the Free Software Foundation; either version 2 of the License, or
 + *  (at your option) any later version.
 + *
 + *  This program is distributed in the hope that it will be useful,
 + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + *  GNU General Public License for more details.
 + *
 + *  You should have received a copy of the GNU General Public License
 + *  along with this program; if not, write to the Free Software
 + *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
 USA
 + */
 +
 +#ifndef _MEDIA_DEVICE_H
 +#define _MEDIA_DEVICE_H
 +
 +#include linux/device.h
 +#include linux/list.h
 +
 +#include media/media-devnode.h
 +
 +/* Each instance of a media device should create the media_device struct,
 + * either stand-alone or embedded in a larger struct.
 + *
 + * It allows easy access to sub-devices (see v4l2-subdev.h) and provides
 + * basic media device-level support.
 + */
 +
 +#define MEDIA_DEVICE_NAME_SIZE (20 + 16)

Where does above numbers come from ??

Regards,
Sergio

 +
 +struct media_device {
 + /* dev-driver_data points to this struct.
 +  * Note: dev might be NULL if there is no parent device
 +  * as is the case with e.g. ISA devices.
 +  */
 + struct device *dev;
 + struct media_devnode devnode;
 +
 + /* unique device name, by default the driver name + bus ID */
 + char name[MEDIA_DEVICE_NAME_SIZE];
 +};
 +
 +int __must_check media_device_register(struct media_device *mdev);
 +void media_device_unregister(struct media_device *mdev);
 +
 +#endif
 --
 1.7.1
 
 --
 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
--
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: [RFC/PATCH 02/10] media: Media device

2010-07-15 Thread Aguirre, Sergio
Hi Laurent,

Other comment I missed to mention...

 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
 Sent: Wednesday, July 14, 2010 8:30 AM
 To: linux-media@vger.kernel.org
 Cc: sakari.ai...@maxwell.research.nokia.com
 Subject: [RFC/PATCH 02/10] media: Media device
 
 The media_device structure abstracts functions common to all kind of
 media devices (v4l2, dvb, alsa, ...). It manages media entities and
 offers a userspace API to discover and configure the media device
 internal topology.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  Documentation/media-framework.txt |   68 
  drivers/media/Makefile|2 +-
  drivers/media/media-device.c  |   77
 +
  include/media/media-device.h  |   53 +
  4 files changed, 199 insertions(+), 1 deletions(-)
  create mode 100644 Documentation/media-framework.txt
  create mode 100644 drivers/media/media-device.c
  create mode 100644 include/media/media-device.h
 

snip

 diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
 new file mode 100644
 index 000..a4d3db5
 --- /dev/null
 +++ b/drivers/media/media-device.c
 @@ -0,0 +1,77 @@
 +/*
 + *  Media device support.
 + *
 + *  Copyright (C) 2010  Laurent Pinchart
 laurent.pinch...@ideasonboard.com
 + *
 + *  This program is free software; you can redistribute it and/or modify
 + *  it under the terms of the GNU General Public License as published by
 + *  the Free Software Foundation; either version 2 of the License, or
 + *  (at your option) any later version.
 + *
 + *  This program is distributed in the hope that it will be useful,
 + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + *  GNU General Public License for more details.
 + *
 + *  You should have received a copy of the GNU General Public License
 + *  along with this program; if not, write to the Free Software
 + *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
 USA
 + */
 +
 +#include linux/types.h
 +#include linux/ioctl.h
 +
 +#include media/media-device.h
 +#include media/media-devnode.h
 +
 +static const struct media_file_operations media_device_fops = {
 + .owner = THIS_MODULE,
 +};
 +
 +static void media_device_release(struct media_devnode *mdev)
 +{
 +}
 +
 +/**
 + * media_device_register - register a media device
 + * @mdev:The media device
 + *
 + * The caller is responsible for initializing the media device before
 + * registration. The following fields must be set:
 + *
 + * - dev should point to the parent device. The field can be NULL when no
 + *   parent device is available (for instance with ISA devices).
 + * - name should be set to the device name. If the name is empty a parent
 + *   device must be set. In that case the name will be set to the parent
 + *   device driver name followed by a space and the parent device name.
 + */
 +int __must_check media_device_register(struct media_device *mdev)
 +{
 + /* If dev == NULL, then name must be filled in by the caller */
 + if (mdev-dev == NULL  WARN_ON(!mdev-name[0]))

If mdev == NULL, you'll have a kernel panic here.

Regards,
Sergio

--
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: [RFC/PATCH 03/10] media: Entities, pads and links

2010-07-15 Thread Aguirre, Sergio
Hi Laurent,

 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
 Sent: Wednesday, July 14, 2010 8:30 AM
 To: linux-media@vger.kernel.org
 Cc: sakari.ai...@maxwell.research.nokia.com
 Subject: [RFC/PATCH 03/10] media: Entities, pads and links

 As video hardware pipelines become increasingly complex and
 configurable, the current hardware description through v4l2 subdevices
 reaches its limits. In addition to enumerating and configuring
 subdevices, video camera drivers need a way to discover and modify at
 runtime how those subdevices are connected. This is done through new
 elements called entities, pads and links.

 An entity is a basic media hardware building block. It can correspond to
 a large variety of logical blocks such as physical hardware devices
 (CMOS sensor for instance), logical hardware devices (a building block
 in a System-on-Chip image processing pipeline), DMA channels or physical
 connectors.

 A pad is a connection endpoint through which an entity can interact with
 other entities. Data (not restricted to video) produced by an entity
 flows from the entity's output to one or more entity inputs. Pads should
 not be confused with physical pins at chip boundaries.

 A link is a point-to-point oriented connection between two pads, either
 on the same entity or on different entities. Data flows from a source
 pad to a sink pad.

 Links are stored in the source entity. To make backwards graph walk
 faster, a copy of all links is also stored in the sink entity. The copy
 is known as a backlink and is only used to help graph traversal.

 The entity API is made of three functions:

 - media_entity_init() initializes an entity. The caller must provide an
 array of pads as well as an estimated number of links. The links array
 is allocated dynamically and will be reallocated if it grows beyond the
 initial estimate.

 - media_entity_cleanup() frees resources allocated for an entity. It
 must be called during the cleanup phase after unregistering the entity
 and before freeing it.

 - media_entity_create_link() creates a link between two entities. An
 entry in the link array of each entity is allocated and stores pointers
 to source and sink pads.

 When a media device is unregistered, all its entities are unregistered
 automatically.

 The code is based on Hans Verkuil hverk...@xs4all.nl initial work.

 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
 ---
  Documentation/media-framework.txt |  125 
  drivers/media/Makefile|2 +-
  drivers/media/media-device.c  |   53 ++
  drivers/media/media-entity.c  |  145
 +
  include/media/media-device.h  |   16 
  include/media/media-entity.h  |   79 
  6 files changed, 419 insertions(+), 1 deletions(-)
  create mode 100644 drivers/media/media-entity.c
  create mode 100644 include/media/media-entity.h

 diff --git a/Documentation/media-framework.txt b/Documentation/media-
 framework.txt
 index b942c8f..4a8f379 100644
 --- a/Documentation/media-framework.txt
 +++ b/Documentation/media-framework.txt
 @@ -35,6 +35,30 @@ belong to userspace.
  The media kernel API aims at solving those problems.


 +Abstract media device model
 +---
 +
 +Discovering a device internal topology, and configuring it at runtime, is
 one
 +of the goals of the media framework. To achieve this, hardware devices
 are
 +modeled as an oriented graph of building blocks called entities connected
 +through pads.
 +
 +An entity is a basic media hardware building block. It can correspond to
 +a large variety of logical blocks such as physical hardware devices
 +(CMOS sensor for instance), logical hardware devices (a building block
 +in a System-on-Chip image processing pipeline), DMA channels or physical
 +connectors.
 +
 +A pad is a connection endpoint through which an entity can interact with
 +other entities. Data (not restricted to video) produced by an entity
 +flows from the entity's output to one or more entity inputs. Pads should
 +not be confused with physical pins at chip boundaries.
 +
 +A link is a point-to-point oriented connection between two pads, either
 +on the same entity or on different entities. Data flows from a source
 +pad to a sink pad.
 +
 +
  Media device
  

 @@ -66,3 +90,104 @@ Drivers unregister media device instances by calling

  Unregistering a media device that hasn't been registered is *NOT* safe.

 +
 +Entities, pads and links
 +
 +
 +- Entities
 +
 +Entities are represented by a struct media_entity instance, defined in
 +include/media/media-entity.h. The structure is usually embedded into a
 +higher-level structure, such as a v4l2_subdev or video_device instance,
 +although drivers can 

[Query] How to preserve soc_camera and still use a sensor for media controller?

2010-06-30 Thread Aguirre, Sergio
Hi all,

Is it possible to keep a sensor chip driver compatible with 2 interfaces?

I'm particularly interested in mt9t112 sensor.

Has this been done before with other driver?

Thanks for your attention.

Regards,
Sergio
--
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: [Query] How to preserve soc_camera and still use a sensor for media controller?

2010-06-30 Thread Aguirre, Sergio
Hi Guennadi,

 -Original Message-
 From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
 Sent: Wednesday, June 30, 2010 1:53 PM
 To: Aguirre, Sergio
 Cc: linux-media@vger.kernel.org
 Subject: Re: [Query] How to preserve soc_camera and still use a sensor for
 media controller?
 
 Hi Sergio
 
 On Wed, 30 Jun 2010, Aguirre, Sergio wrote:
 
  Hi all,
 
  Is it possible to keep a sensor chip driver compatible with 2
 interfaces?
 
  I'm particularly interested in mt9t112 sensor.
 
  Has this been done before with other driver?
 
 You can try looking at this thread:
 http://thread.gmane.org/gmane.linux.drivers.video-input-
 infrastructure/16311

Very interesting thread :)

 and remembering our discussions at the mini-summit;) You can also look at
 Hans' report of summit's results. A few people know, what has to be done,
 but noone has done it yet... The world is still looking for a hero to do
 the job:)

OK, thanks for the info :)

I'll think about that...

Regards,
Sergio
 
 Thanks
 Guennadi
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/
--
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: [media-ctl] [omap3camera:devel] How to use the app?

2010-06-29 Thread Aguirre, Sergio
Hi Laurent,

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Tuesday, June 29, 2010 5:23 AM
 To: Aguirre, Sergio
 Cc: Sakari Ailus; linux-media@vger.kernel.org
 Subject: Re: [media-ctl] [omap3camera:devel] How to use the app?
 
 Hi Sergio,
 
 On Tuesday 29 June 2010 01:34:01 Aguirre, Sergio wrote:
  Hi Laurent/Sakari,
 
  I have been attempting to migrate my IMX046 sensor driver, that I had
  working on my Zoom3(OMAP3630 ES1.1) with older codebase, to work with
 the
  latest omap3camera tree, 'devel' branch:
 
  http://gitorious.org/omap3camera/mainline/commits/devel
 
  And for that, I'm trying to also understand how to use your test tool:
  media-ctl:
 
  http://git.ideasonboard.org/?p=media-ctl.git;a=summary
 
  Now, the thing is that, I don't see any guide to learn how to write the
  Proper format for some of the parameters, like to build links in
  interactive mode (-i), or to set formats (-f).
 
  Can you please detail about a typical usage for this tool? (example on
 how
  to build a link, set link format, etc.)
 
 I've pushed a new patch to the media-ctl repository that makes the help
 message a bit more verbose when running media-ctl -h. It describes the
 links
 and formats as follows:
 
 Links and formats are defined as
   link= pad, '-', pad, '[', flags, ']' ;
   format  = pad, '[', fcc, ' ', size, [ ' ', crop ], ']' ;
   pad = entity, ':', pad number ;
   entity  = entity number | ( '\', entity name, '\' ) ;
   size= width, 'x', height ;
   crop= left, ',', top, '/', size ;
 where the fields are
   entity number   Entity numeric identifier
   entity name Entify name (string)
   pad number  Pad numeric identifier
   flags   Link flags (0: inactive, 1: active)
   fcc Format FourCC
   width   Image width in pixels
   height  Image height in pixels
 
 For instance, to set the CCDC to preview link as active, the link
 specifier
 would be
 
 'OMAP3 ISP CCDC:2 - OMAP3 ISP preview:0 [1]'
 
 To set the format on the preview output pad to YUYV 1280x720, the format
 specifier would be
 
 'OMAP3 ISP preview:2 [YUYV 1280x720]'
 
 Spaces are optional.

Thanks a lot for the explanation, and for the verbose help patch!
That's much better :)

 
  So far, my progress is pushed into this branch:
 
  http://dev.omapzoom.org/?p=saaguirre/linux-omap-
 camera.git;a=shortlog;h=ref
  s/heads/mc_migration_wip
 
 Thanks for the link.
 
  And with that, after I boot, I get the following topology:
 
 [snip]
 
 You will find a set of patches that remove the legacy video nodes attached
 to
 this e-mail. They haven't been applied to the omap3camera tree yet, as we
 still haven't fixed all userspace components yet, but they should get
 there in
 a few weeks hopefully. You should probably apply them to your tree to make
 sure you don't start using the legacy video nodes by mistake. They also
 remove
 a lot of code, which is always good, and remove the hardcoded number of
 sensors.

I had following compilation error:

drivers/media/video/isp/ispvideo.c: In function 'isp_video_streamon':
drivers/media/video/isp/ispvideo.c:780: error: 'const struct 
isp_video_operations' has no member named 'stream_off'
drivers/media/video/isp/ispvideo.c:781: error: 'const struct 
isp_video_operations' has no member named 'stream_off'
make[4]: *** [drivers/media/video/isp/ispvideo.o] Error 1
make[3]: *** [drivers/media/video/isp] Error 2
make[3]: *** Waiting for unfinished jobs
make[2]: *** [drivers/media/video] Error 2
make[1]: *** [drivers/media] Error 2
make: *** [drivers] Error 2

Which I solved with the attached patch. You might want to squash it with your 
patch omap3isp: video: Remove the init, cleanup and stream_off operations

I'll continue trying to bring up my sensor, and let you know if I have other 
query.

Thanks for your time!

Regards,
Sergio

 
 --
 Regards,
 
 Laurent Pinchart


0001-SQUASH-omap3isp-video-Remove-the-init-cleanup-and-st.patch
Description: 0001-SQUASH-omap3isp-video-Remove-the-init-cleanup-and-st.patch


RE: [omap3camera] Kernel broken when building rx51 with camera

2010-06-28 Thread Aguirre, Sergio

 -Original Message-
 From: Aguirre, Sergio
 Sent: Friday, June 25, 2010 9:03 PM
 To: Laurent Pinchart; Sakari Ailus
 Cc: linux-media@vger.kernel.org
 Subject: [omap3camera] Kernel broken when building rx51 with camera
 
 Hi Laurent/Sakari,
 
 Not sure what is exactly happening, but I can't get the kernel
 to build with latest omap3camera gitorious devel branch.
 

Ahh, I just noticed a patch already for it on latest linux-omap tree.

Its an IOMMU bug when building as built-in. Here's the patch:

http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=7d9609c6f0feaf045d5b45fd3e1669837700c152

commit 7d9609c6f0feaf045d5b45fd3e1669837700c152
Author: Hiroshi DOYU hiroshi.d...@nokia.com
Date:   Wed Jun 16 19:05:52 2010 +0300

omap iommu: fix: Make omap-iommu.o built-in

This also fixes the wrong overwritten for obj-y in the previous
commit.

Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com

Sorry for the noise.

Regards,
Sergio

snip
--
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


  1   2   >