Re: [PATCH v9 03/11] media: platform: Add Renesas CEU driver

2018-02-21 Thread jacopo mondi 
Hi Laurent, Hans,

On Wed, Feb 21, 2018 at 02:02:59PM +0100, Hans Verkuil wrote:
> On 02/21/18 13:29, Laurent Pinchart wrote:
> > Hi Hans,
> >
> > On Wednesday, 21 February 2018 14:03:24 EET Hans Verkuil wrote:
> >> On 02/19/18 17:59, Jacopo Mondi wrote:
> >>> Add driver for Renesas Capture Engine Unit (CEU).
> >>>
> >>> The CEU interface supports capturing 'data' (YUV422) and 'images'
> >>> (NV[12|21|16|61]).
> >>>
> >>> This driver aims to replace the soc_camera-based sh_mobile_ceu one.
> >>>
> >>> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> >>> platform GR-Peach.
> >>>
> >>> Tested with ov7725 camera sensor on SH4 platform Migo-R.
> >>>
> >>> Signed-off-by: Jacopo Mondi 
> >>> Reviewed-by: Laurent Pinchart 
> >>> ---
> >>>
> >>>  drivers/media/platform/Kconfig   |9 +
> >>>  drivers/media/platform/Makefile  |1 +
> >>>  drivers/media/platform/renesas-ceu.c | 1661 +
> >>>  3 files changed, 1671 insertions(+)
> >>>  create mode 100644 drivers/media/platform/renesas-ceu.c
> >>
> >> 
> >>
> >>> +static int ceu_s_input(struct file *file, void *priv, unsigned int i)
> >>> +{
> >>> + struct ceu_device *ceudev = video_drvdata(file);
> >>> + struct ceu_subdev *ceu_sd_old;
> >>> + int ret;
> >>> +
> >>> + if (i >= ceudev->num_sd)
> >>> + return -EINVAL;
> >>> +
> >>> + if (vb2_is_streaming(>vb2_vq))
> >>> + return -EBUSY;
> >>> +
> >>> + if (i == ceudev->sd_index)
> >>> + return 0;
> >>> +
> >>> + ceu_sd_old = ceudev->sd;
> >>> + ceudev->sd = >subdevs[i];
> >>> +
> >>> + /* Make sure we can generate output image formats. */
> >>> + ret = ceu_init_formats(ceudev);
> >>
> >> Why is this done for every s_input? I would expect that this is done only
> >> once for each subdev.
> >>
> >> I also expect to see a ceu_set_default_fmt() call here. Or that the 
> >> v4l2_pix
> >> is kept in ceu_subdev (i.e. per subdev) instead of a single fmt in cuedev.
> >> I think I prefer that over configuring a new default format every time you
> >> switch inputs.
> >
> > What does userspace expect today ? I don't think we document anywhere that
> > formats are stored per-input in drivers. The VIDIOC_S_INPUT documentation is
> > very vague:
> >
> > "To select a video input applications store the number of the desired input 
> > in
> > an integer and call the VIDIOC_S_INPUT ioctl with a pointer to this integer.
> > Side effects are possible. For example inputs may support different video
> > standards, so the driver may implicitly switch the current standard. Because
> > of these possible side effects applications must select an input before
> > querying or negotiating any other parameters."
> >
> > I understand that as meaning "anything can happen when you switch inputs, so
> > be prepared to reconfigure everything explicitly without assuming any
> > particular parameter to have a sane value".
> >
> >> This code will work for two subdevs with exactly the same
> >> formats/properties. But switching between e.g. a sensor and a video
> >> receiver will leave things in an inconsistent state as far as I can see.
> >>
> >> E.g. if input 1 is the video receiver then switching to that input and
> >> running 'v4l2-ctl -V' will show the sensor format, not the video receiver
> >> format.
> >
> > I agree that the format should be consistent with the selected input, as
> > calling VIDIOC_S_INPUT immediately followed by a stream start sequence 
> > without
> > configuring formats should work (but produce a format that is not known to
> > userspace). My question is whether we should reset to a default format for 
> > the
> > newly select input, or switch back to the previously set format. I'd tend to
> > go for the former to keep as little state as possible, but I'm open to
> > counter-proposals.
>
> What to do is up to the driver. My personal preference is to make it 
> persistent
> per input, but that's just me. I won't block the other approach (resetting it
> to a default). Be aware that for video receivers the format depends on the 
> current
> selected standard as well. I think the code does that correctly already, but 
> it
> would be good to verify if possible.
>
> BTW, I think it is right that the spec isn't specific about what changes when
> you switch inputs. It can be quite complex for drivers to handle this and it
> is not unreasonable in my view for userspace to just assume it needs to 
> configure
> from scratch after switching inputs.
>

Given that there are not strict requisites here I will go for the
default format selection.

While there I'll rename the ceu_init_formats() function to ceu_init_mbus_fmt() 
as
that's what it actually does, and move ceudev->field initialization
from there  to ceu_set[_default]_fmt() functions.

I'm sending v10 with this changes hopefully quite soon.

Thanks
   j

> Regards,
>
>   Hans
>
> >
> >>> + if (ret) {
> >>> + ceudev->sd =

Re: [PATCH v9 03/11] media: platform: Add Renesas CEU driver

2018-02-21 Thread Hans Verkuil 
On 02/21/18 13:29, Laurent Pinchart wrote:
> Hi Hans,
> 
> On Wednesday, 21 February 2018 14:03:24 EET Hans Verkuil wrote:
>> On 02/19/18 17:59, Jacopo Mondi wrote:
>>> Add driver for Renesas Capture Engine Unit (CEU).
>>>
>>> The CEU interface supports capturing 'data' (YUV422) and 'images'
>>> (NV[12|21|16|61]).
>>>
>>> This driver aims to replace the soc_camera-based sh_mobile_ceu one.
>>>
>>> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
>>> platform GR-Peach.
>>>
>>> Tested with ov7725 camera sensor on SH4 platform Migo-R.
>>>
>>> Signed-off-by: Jacopo Mondi 
>>> Reviewed-by: Laurent Pinchart 
>>> ---
>>>
>>>  drivers/media/platform/Kconfig   |9 +
>>>  drivers/media/platform/Makefile  |1 +
>>>  drivers/media/platform/renesas-ceu.c | 1661 +
>>>  3 files changed, 1671 insertions(+)
>>>  create mode 100644 drivers/media/platform/renesas-ceu.c
>>
>> 
>>
>>> +static int ceu_s_input(struct file *file, void *priv, unsigned int i)
>>> +{
>>> +   struct ceu_device *ceudev = video_drvdata(file);
>>> +   struct ceu_subdev *ceu_sd_old;
>>> +   int ret;
>>> +
>>> +   if (i >= ceudev->num_sd)
>>> +   return -EINVAL;
>>> +
>>> +   if (vb2_is_streaming(>vb2_vq))
>>> +   return -EBUSY;
>>> +
>>> +   if (i == ceudev->sd_index)
>>> +   return 0;
>>> +
>>> +   ceu_sd_old = ceudev->sd;
>>> +   ceudev->sd = >subdevs[i];
>>> +
>>> +   /* Make sure we can generate output image formats. */
>>> +   ret = ceu_init_formats(ceudev);
>>
>> Why is this done for every s_input? I would expect that this is done only
>> once for each subdev.
>>
>> I also expect to see a ceu_set_default_fmt() call here. Or that the v4l2_pix
>> is kept in ceu_subdev (i.e. per subdev) instead of a single fmt in cuedev.
>> I think I prefer that over configuring a new default format every time you
>> switch inputs.
> 
> What does userspace expect today ? I don't think we document anywhere that 
> formats are stored per-input in drivers. The VIDIOC_S_INPUT documentation is 
> very vague:
> 
> "To select a video input applications store the number of the desired input 
> in 
> an integer and call the VIDIOC_S_INPUT ioctl with a pointer to this integer. 
> Side effects are possible. For example inputs may support different video 
> standards, so the driver may implicitly switch the current standard. Because 
> of these possible side effects applications must select an input before 
> querying or negotiating any other parameters."
> 
> I understand that as meaning "anything can happen when you switch inputs, so 
> be prepared to reconfigure everything explicitly without assuming any 
> particular parameter to have a sane value".
> 
>> This code will work for two subdevs with exactly the same
>> formats/properties. But switching between e.g. a sensor and a video
>> receiver will leave things in an inconsistent state as far as I can see.
>>
>> E.g. if input 1 is the video receiver then switching to that input and
>> running 'v4l2-ctl -V' will show the sensor format, not the video receiver
>> format.
> 
> I agree that the format should be consistent with the selected input, as 
> calling VIDIOC_S_INPUT immediately followed by a stream start sequence 
> without 
> configuring formats should work (but produce a format that is not known to 
> userspace). My question is whether we should reset to a default format for 
> the 
> newly select input, or switch back to the previously set format. I'd tend to 
> go for the former to keep as little state as possible, but I'm open to 
> counter-proposals.

What to do is up to the driver. My personal preference is to make it persistent
per input, but that's just me. I won't block the other approach (resetting it
to a default). Be aware that for video receivers the format depends on the 
current
selected standard as well. I think the code does that correctly already, but it
would be good to verify if possible.

BTW, I think it is right that the spec isn't specific about what changes when
you switch inputs. It can be quite complex for drivers to handle this and it
is not unreasonable in my view for userspace to just assume it needs to 
configure
from scratch after switching inputs.

Regards,

Hans

> 
>>> +   if (ret) {
>>> +   ceudev->sd = ceu_sd_old;
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   /* now that we're sure we can use the sensor, power off the old one. */
>>> +   v4l2_subdev_call(ceu_sd_old->v4l2_sd, core, s_power, 0);
>>> +   v4l2_subdev_call(ceudev->sd->v4l2_sd, core, s_power, 1);
>>> +
>>> +   ceudev->sd_index = i;
>>> +
>>> +   return 0;
>>> +}
>>
>> The remainder of this driver looks good.
>

Re: [PATCH v9 03/11] media: platform: Add Renesas CEU driver

2018-02-21 Thread Laurent Pinchart 
Hi Hans,

On Wednesday, 21 February 2018 14:03:24 EET Hans Verkuil wrote:
> On 02/19/18 17:59, Jacopo Mondi wrote:
> > Add driver for Renesas Capture Engine Unit (CEU).
> > 
> > The CEU interface supports capturing 'data' (YUV422) and 'images'
> > (NV[12|21|16|61]).
> > 
> > This driver aims to replace the soc_camera-based sh_mobile_ceu one.
> > 
> > Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> > platform GR-Peach.
> > 
> > Tested with ov7725 camera sensor on SH4 platform Migo-R.
> > 
> > Signed-off-by: Jacopo Mondi 
> > Reviewed-by: Laurent Pinchart 
> > ---
> > 
> >  drivers/media/platform/Kconfig   |9 +
> >  drivers/media/platform/Makefile  |1 +
> >  drivers/media/platform/renesas-ceu.c | 1661 +
> >  3 files changed, 1671 insertions(+)
> >  create mode 100644 drivers/media/platform/renesas-ceu.c
> 
> 
> 
> > +static int ceu_s_input(struct file *file, void *priv, unsigned int i)
> > +{
> > +   struct ceu_device *ceudev = video_drvdata(file);
> > +   struct ceu_subdev *ceu_sd_old;
> > +   int ret;
> > +
> > +   if (i >= ceudev->num_sd)
> > +   return -EINVAL;
> > +
> > +   if (vb2_is_streaming(>vb2_vq))
> > +   return -EBUSY;
> > +
> > +   if (i == ceudev->sd_index)
> > +   return 0;
> > +
> > +   ceu_sd_old = ceudev->sd;
> > +   ceudev->sd = >subdevs[i];
> > +
> > +   /* Make sure we can generate output image formats. */
> > +   ret = ceu_init_formats(ceudev);
> 
> Why is this done for every s_input? I would expect that this is done only
> once for each subdev.
> 
> I also expect to see a ceu_set_default_fmt() call here. Or that the v4l2_pix
> is kept in ceu_subdev (i.e. per subdev) instead of a single fmt in cuedev.
> I think I prefer that over configuring a new default format every time you
> switch inputs.

What does userspace expect today ? I don't think we document anywhere that 
formats are stored per-input in drivers. The VIDIOC_S_INPUT documentation is 
very vague:

"To select a video input applications store the number of the desired input in 
an integer and call the VIDIOC_S_INPUT ioctl with a pointer to this integer. 
Side effects are possible. For example inputs may support different video 
standards, so the driver may implicitly switch the current standard. Because 
of these possible side effects applications must select an input before 
querying or negotiating any other parameters."

I understand that as meaning "anything can happen when you switch inputs, so 
be prepared to reconfigure everything explicitly without assuming any 
particular parameter to have a sane value".

> This code will work for two subdevs with exactly the same
> formats/properties. But switching between e.g. a sensor and a video
> receiver will leave things in an inconsistent state as far as I can see.
> 
> E.g. if input 1 is the video receiver then switching to that input and
> running 'v4l2-ctl -V' will show the sensor format, not the video receiver
> format.

I agree that the format should be consistent with the selected input, as 
calling VIDIOC_S_INPUT immediately followed by a stream start sequence without 
configuring formats should work (but produce a format that is not known to 
userspace). My question is whether we should reset to a default format for the 
newly select input, or switch back to the previously set format. I'd tend to 
go for the former to keep as little state as possible, but I'm open to 
counter-proposals.

> > +   if (ret) {
> > +   ceudev->sd = ceu_sd_old;
> > +   return -EINVAL;
> > +   }
> > +
> > +   /* now that we're sure we can use the sensor, power off the old one. */
> > +   v4l2_subdev_call(ceu_sd_old->v4l2_sd, core, s_power, 0);
> > +   v4l2_subdev_call(ceudev->sd->v4l2_sd, core, s_power, 1);
> > +
> > +   ceudev->sd_index = i;
> > +
> > +   return 0;
> > +}
> 
> The remainder of this driver looks good.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v9 03/11] media: platform: Add Renesas CEU driver

2018-02-21 Thread Hans Verkuil 
On 02/19/18 17:59, Jacopo Mondi wrote:
> Add driver for Renesas Capture Engine Unit (CEU).
> 
> The CEU interface supports capturing 'data' (YUV422) and 'images'
> (NV[12|21|16|61]).
> 
> This driver aims to replace the soc_camera-based sh_mobile_ceu one.
> 
> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> platform GR-Peach.
> 
> Tested with ov7725 camera sensor on SH4 platform Migo-R.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Laurent Pinchart 
> ---
>  drivers/media/platform/Kconfig   |9 +
>  drivers/media/platform/Makefile  |1 +
>  drivers/media/platform/renesas-ceu.c | 1661 
> ++
>  3 files changed, 1671 insertions(+)
>  create mode 100644 drivers/media/platform/renesas-ceu.c
> 



> +static int ceu_s_input(struct file *file, void *priv, unsigned int i)
> +{
> + struct ceu_device *ceudev = video_drvdata(file);
> + struct ceu_subdev *ceu_sd_old;
> + int ret;
> +
> + if (i >= ceudev->num_sd)
> + return -EINVAL;
> +
> + if (vb2_is_streaming(>vb2_vq))
> + return -EBUSY;
> +
> + if (i == ceudev->sd_index)
> + return 0;
> +
> + ceu_sd_old = ceudev->sd;
> + ceudev->sd = >subdevs[i];
> +
> + /* Make sure we can generate output image formats. */
> + ret = ceu_init_formats(ceudev);

Why is this done for every s_input? I would expect that this is done only once
for each subdev.

I also expect to see a ceu_set_default_fmt() call here. Or that the v4l2_pix is 
kept
in ceu_subdev (i.e. per subdev) instead of a single fmt in cuedev. I think I 
prefer
that over configuring a new default format every time you switch inputs.

This code will work for two subdevs with exactly the same formats/properties. 
But
switching between e.g. a sensor and a video receiver will leave things in an
inconsistent state as far as I can see.

E.g. if input 1 is the video receiver then switching to that input and running
'v4l2-ctl -V' will show the sensor format, not the video receiver format.

> + if (ret) {
> + ceudev->sd = ceu_sd_old;
> + return -EINVAL;
> + }
> +
> + /* now that we're sure we can use the sensor, power off the old one. */
> + v4l2_subdev_call(ceu_sd_old->v4l2_sd, core, s_power, 0);
> + v4l2_subdev_call(ceudev->sd->v4l2_sd, core, s_power, 1);
> +
> + ceudev->sd_index = i;
> +
> + return 0;
> +}

The remainder of this driver looks good.

Regards,

Hans

Re: [PATCH v9 03/11] media: platform: Add Renesas CEU driver

2018-02-19 Thread kbuild test robot 
Hi Jacopo,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.16-rc2 next-20180220]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jacopo-Mondi/Renesas-Capture-Engine-Unit-CEU-V4L2-driver/20180220-101027
base:   git://linuxtv.org/media_tree.git master
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/media/platform/renesas-ceu.c: In function 'ceu_g_parm':
>> drivers/media/platform/renesas-ceu.c:1177:9: error: implicit declaration of 
>> function 'v4l2_g_parm_cap'; did you mean 'v4l2_g_ctrl'? 
>> [-Werror=implicit-function-declaration]
 return v4l2_g_parm_cap(video_devdata(file), ceudev->sd->v4l2_sd, a);
^~~
v4l2_g_ctrl
   drivers/media/platform/renesas-ceu.c: In function 'ceu_s_parm':
>> drivers/media/platform/renesas-ceu.c:1184:9: error: implicit declaration of 
>> function 'v4l2_s_parm_cap'; did you mean 'v4l2_s_ctrl'? 
>> [-Werror=implicit-function-declaration]
 return v4l2_s_parm_cap(video_devdata(file), ceudev->sd->v4l2_sd, a);
^~~
v4l2_s_ctrl
   drivers/media/platform/renesas-ceu.c: In function 'ceu_start_streaming':
   drivers/media/platform/renesas-ceu.c:290:2: warning: 'cdwdr' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
 iowrite32(data, priv->base + reg_offs);
 ^~
   drivers/media/platform/renesas-ceu.c:338:27: note: 'cdwdr' was declared here
 u32 camcr, cdocr, cfzsr, cdwdr, capwr;
  ^
   drivers/media/platform/renesas-ceu.c:290:2: warning: 'cfzsr' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
 iowrite32(data, priv->base + reg_offs);
 ^~
   drivers/media/platform/renesas-ceu.c:338:20: note: 'cfzsr' was declared here
 u32 camcr, cdocr, cfzsr, cdwdr, capwr;
   ^
   drivers/media/platform/renesas-ceu.c:418:8: warning: 'camcr' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
 camcr |= mbus_flags & V4L2_MBUS_HSYNC_ACTIVE_LOW ? 1 << 0 : 0;
 ~~^~~
   drivers/media/platform/renesas-ceu.c:338:6: note: 'camcr' was declared here
 u32 camcr, cdocr, cfzsr, cdwdr, capwr;
 ^
   drivers/media/platform/renesas-ceu.c: In function 'ceu_probe':
   drivers/media/platform/renesas-ceu.c:1623:9: warning: 'ret' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
 return ret;
^~~
   cc1: some warnings being treated as errors

vim +1177 drivers/media/platform/renesas-ceu.c

  1172  
  1173  static int ceu_g_parm(struct file *file, void *fh, struct 
v4l2_streamparm *a)
  1174  {
  1175  struct ceu_device *ceudev = video_drvdata(file);
  1176  
> 1177  return v4l2_g_parm_cap(video_devdata(file), 
> ceudev->sd->v4l2_sd, a);
  1178  }
  1179  
  1180  static int ceu_s_parm(struct file *file, void *fh, struct 
v4l2_streamparm *a)
  1181  {
  1182  struct ceu_device *ceudev = video_drvdata(file);
  1183  
> 1184  return v4l2_s_parm_cap(video_devdata(file), 
> ceudev->sd->v4l2_sd, a);
  1185  }
  1186  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH v9 03/11] media: platform: Add Renesas CEU driver

2018-02-19 Thread Jacopo Mondi 
Add driver for Renesas Capture Engine Unit (CEU).

The CEU interface supports capturing 'data' (YUV422) and 'images'
(NV[12|21|16|61]).

This driver aims to replace the soc_camera-based sh_mobile_ceu one.

Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
platform GR-Peach.

Tested with ov7725 camera sensor on SH4 platform Migo-R.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/platform/Kconfig   |9 +
 drivers/media/platform/Makefile  |1 +
 drivers/media/platform/renesas-ceu.c | 1661 ++
 3 files changed, 1671 insertions(+)
 create mode 100644 drivers/media/platform/renesas-ceu.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 614fbef..f9cc058 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -144,6 +144,15 @@ config VIDEO_STM32_DCMI
  To compile this driver as a module, choose M here: the module
  will be called stm32-dcmi.
 
+config VIDEO_RENESAS_CEU
+   tristate "Renesas Capture Engine Unit (CEU) driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
+   depends on ARCH_SHMOBILE || ARCH_R7S72100 || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_FWNODE
+   ---help---
+ This is a v4l2 driver for the Renesas CEU Interface
+
 source "drivers/media/platform/soc_camera/Kconfig"
 source "drivers/media/platform/exynos4-is/Kconfig"
 source "drivers/media/platform/am437x/Kconfig"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 7f30804..85e1121 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_VIDEO_SH_VOU)+= sh_vou.o
 obj-$(CONFIG_SOC_CAMERA)   += soc_camera/
 
 obj-$(CONFIG_VIDEO_RCAR_DRIF)  += rcar_drif.o
+obj-$(CONFIG_VIDEO_RENESAS_CEU)+= renesas-ceu.o
 obj-$(CONFIG_VIDEO_RENESAS_FCP)+= rcar-fcp.o
 obj-$(CONFIG_VIDEO_RENESAS_FDP1)   += rcar_fdp1.o
 obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o
diff --git a/drivers/media/platform/renesas-ceu.c 
b/drivers/media/platform/renesas-ceu.c
new file mode 100644
index 000..d0ac500
--- /dev/null
+++ b/drivers/media/platform/renesas-ceu.c
@@ -0,0 +1,1661 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * V4L2 Driver for Renesas Capture Engine Unit (CEU) interface
+ * Copyright (C) 2017-2018 Jacopo Mondi 
+ *
+ * Based on soc-camera driver "soc_camera/sh_mobile_ceu_camera.c"
+ * Copyright (C) 2008 Magnus Damm
+ *
+ * Based on V4L2 Driver for PXA camera host - "pxa_camera.c",
+ * Copyright (C) 2006, Sascha Hauer, Pengutronix
+ * Copyright (C) 2008, Guennadi Liakhovetski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define DRIVER_NAME"renesas-ceu"
+
+/* CEU registers offsets and masks. */
+#define CEU_CAPSR  0x00 /* Capture start register  */
+#define CEU_CAPCR  0x04 /* Capture control register*/
+#define CEU_CAMCR  0x08 /* Capture interface control register  */
+#define CEU_CAMOR  0x10 /* Capture interface offset register   */
+#define CEU_CAPWR  0x14 /* Capture interface width register*/
+#define CEU_CAIFR  0x18 /* Capture interface input format register */
+#define CEU_CRCNTR 0x28 /* CEU register control register   */
+#define CEU_CRCMPR 0x2c /* CEU register forcible control register  */
+#define CEU_CFLCR  0x30 /* Capture filter control register */
+#define CEU_CFSZR  0x34 /* Capture filter size clip register   */
+#define CEU_CDWDR  0x38 /* Capture destination width register  */
+#define CEU_CDAYR  0x3c /* Capture data address Y register */
+#define CEU_CDACR  0x40 /* Capture data address C register */
+#define CEU_CFWCR  0x5c /* Firewall operation control register */
+#define CEU_CDOCR  0x64 /* Capture data output control register*/
+#define CEU_CEIER  0x70 /* Capture event interrupt enable register */
+#define CEU_CETCR  0x74 /* Capture event flag clear register   */
+#define CEU_CSTSR  0x7c /* Capture status register */
+#define CEU_CSRTR  0x80 /* Capture software reset register */
+
+/* Data synchronous fetch mode. */
+#define CEU_CAMCR_JPEG BIT(4)
+
+/* Input components ordering: CEU_CAMCR.DTARY field. */
+#define CEU_CAMCR_DTARY_8_UYVY (0x00 << 8)
+#define CEU_CAMCR_DTARY_8_VYUY (0x01 << 8)
+#define