soc_camera: SuperH Mobile CEU patches V3

This is V3 of the SuperH Mobile CEU interface patches.

[PATCH 01/06] soc_camera: Move spinlocks
[PATCH 02/06] soc_camera: Add 16-bit bus width support [PATCH 03/06] videobuf: Fix gather spelling
[PATCH 04/06] videobuf: Add physically contiguous queue code V3 [PATCH 05/06] sh_mobile_ceu_camera: Add SuperH Mobile CEU driver V3 [PATCH 06/06] soc_camera_platform: Add SoC Camera Platform driver

Changes since V2:
- use dma_handle for physical address for videobuf-dma-contig
- spell gather correctly
- remove SUPERH Kconfig dependency
- move sh_mobile_ceu.h to include/media
- add board callback support with enable_camera()/disable_camera()
- add support for declare_coherent_memory
- rework video memory limit
- more verbose error messages
- add soc_camera_platform driver for simple camera devices

Changes since V1:
- dropped former V1 patches [01/07]->[04/07]
- rebased on top of [PATCH] soc_camera: make videobuf independent
- rewrote spinlock changes into the new [01/04] patch
- updated the videobuf-dma-contig code with feeback from Paulius Zaleckas
- fixed the CEU driver to work with the newly updated patches

---

 drivers/media/video/Kconfig                |   19 
 drivers/media/video/Makefile               |    3 
 drivers/media/video/pxa_camera.c           |   17 
 drivers/media/video/sh_mobile_ceu_camera.c |  657 ++++++++++++++++++++++++++++
 drivers/media/video/soc_camera.c           |   39 -
 drivers/media/video/soc_camera_platform.c  |  198 ++++++++
 drivers/media/video/videobuf-dma-contig.c  |  417 +++++++++++++++++
 drivers/media/video/videobuf-dma-sg.c      |    2 
 drivers/media/video/videobuf-vmalloc.c     |    2 
 include/media/sh_mobile_ceu.h              |   12 
 include/media/soc_camera.h                 |   12 
 include/media/soc_camera_platform.h        |   15 
 include/media/videobuf-dma-contig.h        |   32 +
 include/media/videobuf-dma-sg.h            |    2 
 include/media/videobuf-vmalloc.h           |    2 
 15 files changed, 1368 insertions(+), 61 deletions(-)

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

This patch moves the spinlock handling from soc_camera.c to the actual camera host driver. The spinlock alloc/free callbacks are replaced with code in init_videobuf().

---

 drivers/media/video/pxa_camera.c |   17 ++++------------
 drivers/media/video/soc_camera.c |   39 --------------------------------------
 include/media/soc_camera.h       |    5 ----
 3 files changed, 7 insertions(+), 54 deletions(-)

@@ -583,12 +583,15 @@ static struct videobuf_queue_ops pxa_vid
 	.buf_release    = pxa_videobuf_release,
 };
 
-static void pxa_camera_init_videobuf(struct videobuf_queue *q, spinlock_t *lock,
+static void pxa_camera_init_videobuf(struct videobuf_queue *q,
 			      struct soc_camera_device *icd)
 {
+	struct soc_camera_host *ici = to_soc_camera_host(icd->dev.parent);
+	struct pxa_camera_dev *pcdev = ici->priv;
+
 	/* We must pass NULL as dev pointer, then all pci_* dma operations
 	 * transform to normal dma_* ones. */
-	videobuf_queue_sg_init(q, &pxa_videobuf_ops, NULL, lock,
+	videobuf_queue_sg_init(q, &pxa_videobuf_ops, NULL, &pcdev->lock,
 				V4L2_BUF_TYPE_VIDEO_CAPTURE, V4L2_FIELD_NONE,
 				sizeof(struct pxa_buffer), icd);
 }

@@ -994,15 +997,6 @@ static int pxa_camera_querycap(struct so
 	return 0;
 }
 
-static spinlock_t *pxa_camera_spinlock_alloc(struct soc_camera_file *icf)
-{
-	struct soc_camera_host *ici =
-		to_soc_camera_host(icf->icd->dev.parent);
-	struct pxa_camera_dev *pcdev = ici->priv;
-
-	return &pcdev->lock;
-}
-
 static struct soc_camera_host_ops pxa_soc_camera_host_ops = {
 	.owner		= THIS_MODULE,
 	.add		= pxa_camera_add_device,

@@ -1015,7 +1009,6 @@ static struct soc_camera_host_ops pxa_so
 	.querycap	= pxa_camera_querycap,
 	.try_bus_param	= pxa_camera_try_bus_param,
 	.set_bus_param	= pxa_camera_set_bus_param,
-	.spinlock_alloc	= pxa_camera_spinlock_alloc,
 };
 
 /* Should be allocated dynamically too, but we have only one. */

@@ -183,7 +183,6 @@ static int soc_camera_open(struct inode 
 	struct soc_camera_device *icd;
 	struct soc_camera_host *ici;
 	struct soc_camera_file *icf;
-	spinlock_t *lock;
 	int ret;
 
 	icf = vmalloc(sizeof(*icf));

@@ -210,13 +209,6 @@ static int soc_camera_open(struct inode 
 	}
 
 	icf->icd = icd;
-
-	icf->lock = ici->ops->spinlock_alloc(icf);
-	if (!icf->lock) {
-		ret = -ENOMEM;
-		goto esla;
-	}
-
 	icd->use_count++;
 
 	/* Now we really have to activate the camera */

@@ -234,17 +226,12 @@ static int soc_camera_open(struct inode 
 	file->private_data = icf;
 	dev_dbg(&icd->dev, "camera device open\n");
 
-	ici->ops->init_videobuf(&icf->vb_vidq, icf->lock, icd);
+	ici->ops->init_videobuf(&icf->vb_vidq, icd);
 
 	return 0;
 
 	/* All errors are entered with the video_lock held */
 eiciadd:
-	lock = icf->lock;
-	icf->lock = NULL;
-	if (ici->ops->spinlock_free)
-		ici->ops->spinlock_free(lock);
-esla:
 	module_put(ici->ops->owner);
 emgi:
 	module_put(icd->ops->owner);

@@ -260,15 +247,11 @@ static int soc_camera_close(struct inode
 	struct soc_camera_device *icd = icf->icd;
 	struct soc_camera_host *ici = to_soc_camera_host(icd->dev.parent);
 	struct video_device *vdev = icd->vdev;
-	spinlock_t *lock = icf->lock;
 
 	mutex_lock(&video_lock);
 	icd->use_count--;
 	if (!icd->use_count)
 		ici->ops->remove(icd);
-	icf->lock = NULL;
-	if (ici->ops->spinlock_free)
-		ici->ops->spinlock_free(lock);
 	module_put(icd->ops->owner);
 	module_put(ici->ops->owner);
 	mutex_unlock(&video_lock);

@@ -764,21 +747,6 @@ static void dummy_release(struct device 
 {
 }
 
-static spinlock_t *spinlock_alloc(struct soc_camera_file *icf)
-{
-	spinlock_t *lock = kmalloc(sizeof(spinlock_t), GFP_KERNEL);
-
-	if (lock)
-		spin_lock_init(lock);
-
-	return lock;
-}
-
-static void spinlock_free(spinlock_t *lock)
-{
-	kfree(lock);
-}
-
 int soc_camera_host_register(struct soc_camera_host *ici)
 {
 	int ret;

@@ -808,11 +776,6 @@ int soc_camera_host_register(struct soc_
 	if (ret)
 		goto edevr;
 
-	if (!ici->ops->spinlock_alloc) {
-		ici->ops->spinlock_alloc = spinlock_alloc;
-		ici->ops->spinlock_free = spinlock_free;
-	}
-
 	scan_add_host(ici);
 
 	return 0;

@@ -48,7 +48,6 @@ struct soc_camera_device {
 struct soc_camera_file {
 	struct soc_camera_device *icd;
 	struct videobuf_queue vb_vidq;
-	spinlock_t *lock;
 };
 
 struct soc_camera_host {

@@ -67,15 +66,13 @@ struct soc_camera_host_ops {
 	int (*set_fmt_cap)(struct soc_camera_device *, __u32,
 			   struct v4l2_rect *);
 	int (*try_fmt_cap)(struct soc_camera_device *, struct v4l2_format *);
-	void (*init_videobuf)(struct videobuf_queue*, spinlock_t *,
+	void (*init_videobuf)(struct videobuf_queue *,
 			      struct soc_camera_device *);
 	int (*reqbufs)(struct soc_camera_file *, struct v4l2_requestbuffers *);
 	int (*querycap)(struct soc_camera_host *, struct v4l2_capability *);
 	int (*try_bus_param)(struct soc_camera_device *, __u32);
 	int (*set_bus_param)(struct soc_camera_device *, __u32);
 	unsigned int (*poll)(struct file *, poll_table *);
-	spinlock_t* (*spinlock_alloc)(struct soc_camera_file *);
-	void (*spinlock_free)(spinlock_t *);
 };
 
 struct soc_camera_link {

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

As merits of this move were not quite obvious to me (you lose the possibility to use default lock allocation / freeing in soc_camera.c), I extended your comment as follows:

This patch moves the spinlock handling from soc_camera.c to the actual camera host driver. The spinlock_alloc/free callbacks are replaced with code in init_videobuf(). So far all camera host drivers implement their own spinlock_alloc/free methods anyway, and videobuf_queue_core_init() BUGs on a NULL spinlock argument, so, new camera host drivers will not forget to provide a spinlock when initialising their videobug queues.

Do you agree with it? This is how I'm going to pull it into my soc-camera tree.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

                                                        videobuf
                                                               ^

Thanks:-)

Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

Yes, I agree. Thanks for extending the comment.

Speaking about pulling in patches, are all 6 patches ok with you guys? Or do you expect me to fix up and resend something?

/ magnus

The SuperH Mobile CEU hardware supports 16-bit width bus, so extend the soc_camera code with SOCAM_DATAWIDTH_16.

---

 include/media/soc_camera.h |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

@@ -153,11 +153,12 @@ static inline struct v4l2_queryctrl cons
 #define SOCAM_DATAWIDTH_8		(1 << 6)
 #define SOCAM_DATAWIDTH_9		(1 << 7)
 #define SOCAM_DATAWIDTH_10		(1 << 8)
-#define SOCAM_PCLK_SAMPLE_RISING	(1 << 9)
-#define SOCAM_PCLK_SAMPLE_FALLING	(1 << 10)
+#define SOCAM_DATAWIDTH_16		(1 << 9)
+#define SOCAM_PCLK_SAMPLE_RISING	(1 << 10)
+#define SOCAM_PCLK_SAMPLE_FALLING	(1 << 11)
 
 #define SOCAM_DATAWIDTH_MASK (SOCAM_DATAWIDTH_8 | SOCAM_DATAWIDTH_9 | \
-			      SOCAM_DATAWIDTH_10)
+			      SOCAM_DATAWIDTH_10 | SOCAM_DATAWIDTH_16)
 
 static inline unsigned long soc_camera_bus_param_compatible(
 			unsigned long camera_flags, unsigned long bus_flags)

Use "scatter gather" instead of "scatter gatter".

---

 drivers/media/video/videobuf-dma-sg.c  |    2 +-
 drivers/media/video/videobuf-vmalloc.c |    2 +-
 include/media/videobuf-dma-sg.h        |    2 +-
 include/media/videobuf-vmalloc.h       |    2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

@@ -1,7 +1,7 @@
 /*
  * helper functions for SG DMA video4linux capture buffers
  *
- * The functions expect the hardware being able to scatter gatter
+ * The functions expect the hardware being able to scatter gather
  * (i.e. the buffers are not linear in physical memory, but fragmented
  * into PAGE_SIZE chunks).  They also assume the driver does not need
  * to touch the video data.

@@ -1,7 +1,7 @@
 /*
  * helper functions for vmalloc video4linux capture buffers
  *
- * The functions expect the hardware being able to scatter gatter
+ * The functions expect the hardware being able to scatter gather
  * (i.e. the buffers are not linear in physical memory, but fragmented
  * into PAGE_SIZE chunks).  They also assume the driver does not need
  * to touch the video data.

@@ -1,7 +1,7 @@
 /*
  * helper functions for SG DMA video4linux capture buffers
  *
- * The functions expect the hardware being able to scatter gatter
+ * The functions expect the hardware being able to scatter gather
  * (i.e. the buffers are not linear in physical memory, but fragmented
  * into PAGE_SIZE chunks).  They also assume the driver does not need
  * to touch the video data.

@@ -1,7 +1,7 @@
 /*
  * helper functions for vmalloc capture buffers
  *
- * The functions expect the hardware being able to scatter gatter
+ * The functions expect the hardware being able to scatter gather
  * (i.e. the buffers are not linear in physical memory, but fragmented
  * into PAGE_SIZE chunks).  They also assume the driver does not need
  * to touch the video data.

This is V3 of the physically contiguous videobuf queues patch. Useful for hardware such as the SuperH Mobile CEU which doesn't support scatter gatter bus mastering.

Since it may be difficult to allocate large chunks of physically contiguous memory after some uptime due to fragmentation, this code allocates memory using dma_alloc_coherent(). Architectures supporting dma_declare_coherent_memory() can easily avoid fragmentation issues by using dma_declare_coherent_memory() to force dma_alloc_coherent() to allocate from a certain pre-allocated memory area.

---

Changes since V2
- use dma_handle for physical address
- use "scatter gather" instead of "scatter gatter"

Changes since V1:
- use dev_err() instead of pr_err()
- remember size in struct videobuf_dma_contig_memory
- keep struct videobuf_dma_contig_memory in .c file
- let videobuf_to_dma_contig() return dma_addr_t
- implement __videobuf_sync()
- return statements, white space and other minor fixes

 drivers/media/video/Kconfig               |    5 
 drivers/media/video/Makefile              |    1 
 drivers/media/video/videobuf-dma-contig.c |  417 +++++++++++++++++++++++++++++
 include/media/videobuf-dma-contig.h       |   32 ++
 4 files changed, 455 insertions(+)

@@ -24,6 +24,11 @@ config VIDEOBUF_VMALLOC
 	select VIDEOBUF_GEN
 	tristate
 
+config VIDEOBUF_DMA_CONTIG
+	depends on HAS_DMA
+	select VIDEOBUF_GEN
+	tristate
+
 config VIDEOBUF_DVB
 	tristate
 	select VIDEOBUF_GEN

@@ -88,6 +88,7 @@ obj-$(CONFIG_VIDEO_TUNER) += tuner.o
 
 obj-$(CONFIG_VIDEOBUF_GEN) += videobuf-core.o
 obj-$(CONFIG_VIDEOBUF_DMA_SG) += videobuf-dma-sg.o
+obj-$(CONFIG_VIDEOBUF_DMA_CONTIG) += videobuf-dma-contig.o
 obj-$(CONFIG_VIDEOBUF_VMALLOC) += videobuf-vmalloc.o
 obj-$(CONFIG_VIDEOBUF_DVB) += videobuf-dvb.o
 obj-$(CONFIG_VIDEO_BTCX)  += btcx-risc.o

@@ -0,0 +1,32 @@
+/*
+ * helper functions for physically contiguous capture buffers
+ *
+ * The functions support hardware lacking scatter gather support
+ * (i.e. the buffers must be linear in physical memory)
+ *
+ * Copyright (c) 2008 Magnus Damm
+ *
+ * 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
+ */
+#ifndef _VIDEOBUF_DMA_CONTIG_H
+#define _VIDEOBUF_DMA_CONTIG_H
+
+#include <linux/dma-mapping.h>
+#include <media/videobuf-core.h>
+
+void videobuf_queue_dma_contig_init(struct videobuf_queue *q,
+				    struct videobuf_queue_ops *ops,
+				    struct device *dev,
+				    spinlock_t *irqlock,
+				    enum v4l2_buf_type type,
+				    enum v4l2_field field,
+				    unsigned int msize,
+				    void *priv);
+
+dma_addr_t videobuf_to_dma_contig(struct videobuf_buffer *buf);
+void videobuf_dma_contig_free(struct videobuf_queue *q,
+			      struct videobuf_buffer *buf);
+
+#endif /* _VIDEOBUF_DMA_CONTIG_H */

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

                   gather
                      ^

This is V3 of the SuperH Mobile CEU soc_camera driver.

The CEU hardware block is configured in a transparent data fetch mode, frames are captured from the attached camera and written to physically contiguous memory buffers provided by the newly added videobuf-dma-contig queue. Tested on sh7722 and sh7723 processors.

---

Changes since V2:
- remove SUPERH Kconfig dependency
- move sh_mobile_ceu.h to include/media
- add board callback support with enable_camera()/disable_camera()
- add support for declare_coherent_memory
- rework video memory limit
- more verbose error messages

Changes since V1:
- fixed the CEU driver to work with the newly updated patches

 drivers/media/video/Kconfig                |    8 
 drivers/media/video/Makefile               |    1 
 drivers/media/video/sh_mobile_ceu_camera.c |  657 ++++++++++++++++++++++++++++
 include/media/sh_mobile_ceu.h              |   12 
 4 files changed, 678 insertions(+)

@@ -958,4 +958,12 @@ config VIDEO_PXA27x
 	---help---
 	  This is a v4l2 driver for the PXA27x Quick Capture Interface
 
+config VIDEO_SH_MOBILE_CEU
+	tristate "SuperH Mobile CEU Interface driver"
+	depends on VIDEO_DEV
+	select SOC_CAMERA
+	select VIDEOBUF_DMA_CONTIG
+	---help---
+	  This is a v4l2 driver for the SuperH Mobile CEU Interface
+
 endif # VIDEO_CAPTURE_DRIVERS

@@ -131,6 +131,7 @@ obj-$(CONFIG_VIDEO_VIVI) += vivi.o
 obj-$(CONFIG_VIDEO_CX23885) += cx23885/
 
 obj-$(CONFIG_VIDEO_PXA27x)	+= pxa_camera.o
+obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)	+= sh_mobile_ceu_camera.o
 obj-$(CONFIG_SOC_CAMERA)	+= soc_camera.o
 obj-$(CONFIG_SOC_CAMERA_MT9M001)	+= mt9m001.o
 obj-$(CONFIG_SOC_CAMERA_MT9V022)	+= mt9v022.o

@@ -0,0 +1,12 @@
+#ifndef __ASM_SH_MOBILE_CEU_H__
+#define __ASM_SH_MOBILE_CEU_H__
+
+#include <media/soc_camera.h>
+
+struct sh_mobile_ceu_info {
+	unsigned long flags; /* SOCAM_... */
+	void (*enable_camera)(void);
+	void (*disable_camera)(void);
+};
+
+#endif /* __ASM_SH_MOBILE_CEU_H__ */

Hi Magnus,

the whole this patch-series has been pulled into the v4l tree now, which means there hasn't been any critical issues left, at least none are known:-)

A couple of general notes, that would be nice to address in an incremental patch:

1. the driver could benefit from a bit more comments:-) At least for register configuration.

2. code like

Hi Guennadi!

Excellent! Thank you.

Yes, I agree with you.

Yeah, sorry about that. The sequence above is pure magic, but it would definitely not hurt with a few constants...

I've done some stress testing and I've had the camera running over the weekend on a sh7723 board without problems, so i guess the driver is at least half-ok.

This doesn't mean you're wrong though, there is definitely a need for better error handling. There are many bits available for error conditions - I guess the biggest question is how to trigger them and what to do about it.

I'm sure Paul would ack if you guys needed it, but i wonder if there is any point in it. Paul knows about this work and he will sign off on the platform data part for sure. So I wouldn't worry about it if I were you.

This memory could on-chip SRAM, but right now it's regular external RAM. It's up to the person fixing up the platform data to decide, and I think that's a pretty nice and flexible strategy.

I plan on doing something like this for the platform data:
http://git.kernel.org/?p=linux/kernel/git/lethal/sh-2.6.git;a=commitdiff;h;a5b04f107f462ec14994270e15b91c59041ef9

Regarding request_mem_region() - I used to add that here and there, but I think the platform driver layer should handle that for us automatically these days. I'm not 100% sure though. =)

Thanks for all the help!

/ magnus

Not sure how you have done your stress-testing, but, I think, it should be possible to generate a couple of DMA overruns, if you put the CPU under load, add at least one more DMA source under load - don't know what you can use on SH, but USB (e.g., bluetooth), FB are usually good at this, add some interrupt flood, so, you have a good chance to be late with your video-interrupt processing. And let your camera run at a good frame-rate...

As for handling, at least checking for some of those bits with some comment "if you see this triggered, let me know, we'll decide how to handle this", and a nice printk, maybe ratelimited... The rest, like dropping the frame might indeed not be easy to get right without a test-case.

Ok.

I had a short look and didn't find anything like that there... So, you might want to double-check and add if needed.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

Yes, I remain completely impartial to this entire series:

It's a bit obscured, but it's certainly handled generically these days.

Look at drivers/base/platform.c:platform_device_add(). The resource type is checked there and handed off to insert_resource(). platform_device_add() is likewise wrapped in to from platform_device_register(), so everyone claims the resources unconditionally.

Sorry, I still don't qite follow. _Resources_ get accounted with the platform_device_add() / platform_device_del(), and are searched by platform_get_resource(), but even this doesn't lock the resource like some other "get" methods. I can see that. But we are talking not about "struct resource" accounting, but about memory regions. And I don't see this done anywhere in platform-device / resource handling.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

Uhm, what? What do you think request_mem_region() does? It most certainly is about struct resource accounting, and the use of insert_resource() is very clearly documented in kernel/resource.c.

If you have an IORESOURCE_MEM resource in your platform device, the iomem_resource pointer gets referenced, just as with request_mem_region(), and they both go through __request_region(). The only difference is that request_mem_region() doesn't permit nesting, while insert_resource() does. There's nothing else going on here.

platform_get_resource() has nothing to do with platform_device_add() setting up resources, it's just a helper to find a struct resource by its IORESOURCE type nested in the platform device, as they are very often out of order. platform_get_irq() tends to be the most useful of these.

Indeed, I was so used to request_mem_region() that I didn't think about it in terms of "struct resource" management. I stand corrected.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

This patch adds a simple platform camera device. Useful for testing cameras with SoC camera host drivers. Only one single pixel format and resolution combination is supported.

---

 drivers/media/video/Kconfig               |    6 
 drivers/media/video/Makefile              |    1 
 drivers/media/video/soc_camera_platform.c |  198 +++++++++++++++++++++++++++++
 include/media/soc_camera_platform.h       |   15 ++
 4 files changed, 220 insertions(+)

@@ -950,6 +950,12 @@ config MT9V022_PCA9536_SWITCH
 	  Select this if your MT9V022 camera uses a PCA9536 I2C GPIO
 	  extender to switch between 8 and 10 bit datawidth modes
 
+config SOC_CAMERA_PLATFORM
+	tristate "platform camera support"
+	depends on SOC_CAMERA
+	help
+	  This is a generic SoC camera platform driver, useful for testing
+
 config VIDEO_PXA27x
 	tristate "PXA27x Quick Capture Interface driver"
 	depends on VIDEO_DEV && PXA27x

@@ -135,6 +135,7 @@ obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)	+= sh_
 obj-$(CONFIG_SOC_CAMERA)	+= soc_camera.o
 obj-$(CONFIG_SOC_CAMERA_MT9M001)	+= mt9m001.o
 obj-$(CONFIG_SOC_CAMERA_MT9V022)	+= mt9v022.o
+obj-$(CONFIG_SOC_CAMERA_PLATFORM)	+= soc_camera_platform.o
 
 obj-$(CONFIG_VIDEO_AU0828) += au0828/
 

@@ -0,0 +1,15 @@
+#ifndef __SOC_CAMERA_H__
+#define __SOC_CAMERA_H__
+
+#include <linux/videodev2.h>
+
+struct soc_camera_platform_info {
+	int iface;
+	char *format_name;
+	unsigned long format_depth;
+	struct v4l2_pix_format format;
+	unsigned long bus_param;
+	int (*set_capture)(struct soc_camera_platform_info *info, int enable);
+};
+
+#endif /* __SOC_CAMERA_H__ */

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Thanks, applied to soc-camera.

Guennadi
---
Guennadi Liakhovetski