Re: [PATCH 2/8] marvell-cam: Separate out the Marvell camera core
2011/6/23 Jonathan Corbet cor...@lwn.net: [Sorry, I'm just now recovering from one of those total-loss-of-inbox-control episodes...] On Fri, 17 Jun 2011 11:11:33 +0800 Kassey Lee kassey1...@gmail.com wrote: the problem is: when we stop CCIC, and then switch to another format. at this stage, actually, CCIC DMA is not stopped until the transferring frame is done. this will cause system hang if we start CCIC again with another format. OK, I've never encountered that. The use case I'm coding for (OLPC) doesn't involve a whole lot of format changes; generally they pick a format for their record activity based on what works best on the display side and stick with it. that is different with our stress test case. from your logic, when stop DMA, you are test the EOF/SOF, so I wonder why you want to do this ? and is your test will stop CCIC and start CCIC frequently ? I wanted a way to know whether DMA was active or not; the idea was that an SOF indicates that things are starting, EOF says that it's done. Are you saying that there can be DMA active in the period after an EOF when the subsequent SOF has not been received? this is OK if we are streaming data. but the point is CCIC DMA won't stop even we stop CCIC until the transferring frame is done. Thanks, jon -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- 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: no mmu on videobuf2
2011/6/16 Scott Jiang scott.jiang.li...@gmail.com: 2011/6/16 Marek Szyprowski m.szyprow...@samsung.com: Hello Scott, Hi Marek and Laurent, I am working on v4l2 drivers for blackfin which is a no mmu soc. I found videobuf allocate memory in mmap not reqbuf, so I turn to videobuf2. But __setup_offsets() use plane offset to fill m.offset, which is always 0 for single-planar buffer. So pgoff in get_unmapped_area callback equals 0. I only found uvc handled get_unmapped_area for no mmu system, but it manages buffers itself. I really want videobuf2 to manage buffers. Please give me some advice. I'm not really sure if I know the differences between mmu and no-mmu systems (from the device driver perspective). I assume that you are using videobuf2-vmalloc allocator. Note that memory allocators/managers are well separated from the videobuf2 logic. If it the current one doesn't serve you well you can make your own no-mmu allocator. Later once we identify all differences it might be merged with the standard one or left alone if the merge is not really possible or easy. Best regards -- Marek Szyprowski Samsung Poland RD Center Hi Marek, I used dma-contig allocator. I mean if offset is 0, I must get actual addr from this offset. hi, Scott if it is single plane, surely the offset is 0 for plane 0 what do you mean the actual addr ? __find_plane_by_offset can do this. But it is an internal function. I think there should be a function called vb2_get_unmapped_area to do this in framework side. are you using soc_camera ? you can add your get_unmapped_area in soc_camera. if not, you can add it in your v4l2_file_operations ops, while still using videbuf2 to management your buffer. Regards, Scott -- 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 -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- 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 2/8] marvell-cam: Separate out the Marvell camera core
2011/6/17 Mauro Carvalho Chehab mche...@infradead.org:
Em 15-06-2011 23:30, Kassey Lee escreveu:
2011/6/14 Jonathan Corbet cor...@lwn.net:
On Tue, 14 Jun 2011 10:58:47 +0800
Kassey Lee kassey1...@gmail.com wrote:
+ /*
+ * Try to find the sensor.
+ */
+ cam-sensor_addr = ov7670_info.addr;
+ cam-sensor = v4l2_i2c_new_subdev_board(cam-v4l2_dev,
+ cam-i2c_adapter, ov7670_info, NULL);
I do not thinks so.
I don't understand what this comment is meant to mean...?
this should be move out to arch/arm/mach-xxx/board.c
Please drop the parts that you're not commenting. It is very hard to find a
one-line
comment in the middle of a long patch, especially since you don't even add
blank
lines before/after it.
sorry for the confusion.
this is the same idea that we want to separate the ccic driver and sensor info.
here is how we do this:
on arch/arm/mach-mmp/ttc_dkb.c
static struct i2c_board_info dkb_i2c_camera[] = {
{
I2C_BOARD_INFO(ov5642, 0x3c),
},
};
i2c_register_board_info(0, dkb_i2c_camera, 1);
With respect to your comment, it doesn't makes much sense,as cafe_ccic
runs on OLPC 1 hardware (at least the version I have here) is x86-based.
that is fine, sorry, i always thought it was ARM platform.
So, I'm not seeing any reason why not apply patch 2/8.
Applying on my tree.
Mauro.
--
Best regards
Kassey
Application Processor Systems Engineering, Marvell Technology Group Ltd.
Shanghai, China.
--
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 2/8] marvell-cam: Separate out the Marvell camera core
2011/6/16 Jonathan Corbet cor...@lwn.net: On Thu, 16 Jun 2011 11:12:03 +0800 Kassey Lee kassey1...@gmail.com wrote: 2) for mcam_ctlr_stop_dma implementation, I guess you know something about the silicon limitation, but we found it can not pass our stress test(1000 times capture test, which will switch format between JPEG and YUV again and again). our solution is : stop the ccic controller and wait for about one frame transfer time, and the stop the sensor. this passed our stress test. for your info. Actually, I know very little that's not in the datasheet. Are you telling me that there are hardware limitations that aren't documented, and that the datasheet is not a 100% accurate description of what's going on? I'm *shocked* I tell you! (For the record, with both Cafe and Armada 610, I've found the hardware to be more reasonable and in accord with the documentation than with many others.) In any case, I don't know about the limitation you're talking about here, could you elaborate a bit? For stress testing I've run video capture for weeks at a time, so obviously you're talking about something else. Sounds like something I need to know? hi, Jon: the problem is: when we stop CCIC, and then switch to another format. at this stage, actually, CCIC DMA is not stopped until the transferring frame is done. this will cause system hang if we start CCIC again with another format. we've ask silicon design to add CCIC DMA stop/start controller bit. from your logic, when stop DMA, you are test the EOF/SOF, so I wonder why you want to do this ? and is your test will stop CCIC and start CCIC frequently ? thanks 3) for videoubuf2, will you use videoubuf2 only or combined with soc-camera ? when can your driver for videoubuf2 ready ? Videobuf2 only. To be honest, I've never quite understood what soc-camera buys. If there's a reason to do a switch, it could be contemplated - but remember that Cafe is not an SoC device. The vb2 driver is working now in vmalloc mode, which is probably what Cafe will need forever. I do plan to add dma-contig, and, probably, dma-sg support in the very near future. If you want, I can post the vmalloc version later today; I just want to make one more pass over it first. could you please share the vmalloc way to me ? and if the dma-contig is OK, I'm glad to verify on our platform. as to test USERPTR, we are using a PMEM to get phy-contig memory in user space, and then QBUF to driver. 4) the point is: ccic and sensor driver should be independent, and support two CCIC controller. No disagreement there. I believe that two controllers should work now - though there's probably a gotcha somewhere since it's not actually been tried. Thanks, jon -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- 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: soc_camera_set_fmt in soc_camera_open
2011/6/13 Guennadi Liakhovetski g.liakhovet...@gmx.de: On Mon, 13 Jun 2011, Kassey Lee wrote: On Fri, Jun 10, 2011 at 5:16 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Fri, 10 Jun 2011, Kassey Lee wrote: hi, Guennadi: in drivers/media/video/soc_camera.c static int soc_camera_open(struct file *file) it will call soc_camera_set_fmt to configure the sensor and host controller. for sensor, this means it will trigger download setting, this may take quite time through i2c or SPI. I complain about this, because after we open, request, s_param, S_FMT, DQBUF, in S_FMT, we will download the setting again. how do you think ? If it's a concern for you, you might consider moving most of your sensor set up from .s_(mbus_)fmt() to .s_stream(). Would that solve your problem? .s_stream can not pass the fmt info, because we need download different setting depends on the format(UYVY, resolution, JPEG) Of course it cannot. You would have to store it in your .s_(mbus_)fmt() method and use during .s_stream(). what I can figure out in open is power up sensor, why we need to .s_fmt() in open ? The ideas behind this decision were to (1) make it simple for the drivers to comply with the specification's requirements to preserve the configuration across close() / open() calls, to be able to start streaming data directly after open() without any S_FMT ioctl()s, and to allow the hardware to be powered down when unused, and to (2) initialise internal format translation tables and other data. We could try to slightly optimise this by only calling soc_camera_set_fmt() during STREAMON _if_ no S_FMT has been called explicitly. But that would be a larger change, than just adjusting your driver. You could do another optimisation yourself too: if the new configuration is equal to the currently configured one, you don't issue any i2c commands. OK, I will hack our driver to optimize this. thanks! Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- 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 2/8] marvell-cam: Separate out the Marvell camera core
2011/6/14 Jonathan Corbet cor...@lwn.net:
On Tue, 14 Jun 2011 10:58:47 +0800
Kassey Lee kassey1...@gmail.com wrote:
+#include linux/wait.h
+#include linux/delay.h
+#include linux/io.h
+
Would be good to sort headers alphabetically
Um, I suppose. You're sure you don't want inverse Christmas-tree ordering?
:)
+static int cafe_smbus_write_done(struct mcam_camera *mcam)
+{
+ unsigned long flags;
+ int c1;
+
+ /*
+ * We must delay after the interrupt, or the controller gets
confused
+ * and never does give us good status. Fortunately, we don't do
this
+ * often.
+ */
+ udelay(20);
+ spin_lock_irqsave(mcam-dev_lock, flags);
+ c1 = mcam_reg_read(mcam, REG_TWSIC1);
+ spin_unlock_irqrestore(mcam-dev_lock, flags);
do you really want to use spin_lock to protect REG_TWSIC1, this
register is not access in ISR ?
I use the spinlock to protect all accesses to the MMIO space; I don't think
it makes sense to have multiple threads mucking around in there at ths same
time.
Also, once again, this is a reshuffle of code which has worked for years; I
don't think it's the right time to mess with the locking decisions.
OK, that is fine.
+/*
+ * Controller-level stuff
+ */
+
+static void cafe_ctlr_init(struct mcam_camera *mcam)
cafe_init is enough
Disagree. This is controller-level (as opposed to TWSI) programming, so
the related functions have ctlr in them. This doesn't seem like a level
of detail that needs a great deal of discussion...?
+#define cam_err(cam, fmt, arg...) \
+ dev_err((cam)-dev, fmt, ##arg);
+#define cam_warn(cam, fmt, arg...) \
+ dev_warn((cam)-dev, fmt, ##arg);
+#define cam_dbg(cam, fmt, arg...) \
+ dev_dbg((cam)-dev, fmt, ##arg);
+
you 've define these in cafe_driver.c, better to share one
Do look at the cafe version:
#define cam_err(cam, fmt, arg...) \
dev_err((cam)-pdev-dev, fmt, ##arg);
They're not the same, so can't be shared. Probably the cafe ones should be
renamed to cafe_err() or whatever to avoid this sort of confusion.
+static void mcam_ctlr_image(struct mcam_camera *cam)
+{
+ int imgsz;
+ struct v4l2_pix_format *fmt = cam-pix_format;
+
+ imgsz = ((fmt-height IMGSZ_V_SHIFT) IMGSZ_V_MASK) |
+ (fmt-bytesperline IMGSZ_H_MASK);
Superfluous parenthesis
See http://lwn.net/Articles/382023/ :)
I feel that use of parentheses to make order of evaluation in complex
expressions explicit is no sin.
+static void mcam_ctlr_irq_enable(struct mcam_camera *cam)
mcam_irq_enable is OK
Sure, it would be OK; there isn't the distinction with the TWSI IRQs that
the cafe driver has. I also don't think that the longer name contributes
greatly to global warming.
+/*
+ * We have found the sensor on the i2c. Let's try to have a
+ * conversation.
+ */
+static int mcam_cam_init(struct mcam_camera *cam)
+{
+ struct v4l2_dbg_chip_ident chip;
+ int ret;
+
+ mutex_lock(cam-s_mutex);
+ if (cam-state != S_NOTREADY)
+ cam_warn(cam, Cam init with device in funky state %d,
+ cam-state);
+ ret = __mcam_cam_reset(cam);
+ if (ret)
+ goto out;
+ chip.ident = V4L2_IDENT_NONE;
+ chip.match.type = V4L2_CHIP_MATCH_I2C_ADDR;
+ chip.match.addr = cam-sensor_addr;
+ ret = sensor_call(cam, core, g_chip_ident, chip);
+ if (ret)
+ goto out;
+ cam-sensor_type = chip.ident;
+ if (cam-sensor_type != V4L2_IDENT_OV7670) {
again, CCIC do not need to know sensor's name.
And, again, that will be fixed. But that's a job for a separate patch.
+static int mcam_vidioc_reqbufs(struct file *filp, void *priv,
+ struct v4l2_requestbuffers *req)
+{
+ struct mcam_camera *cam = filp-private_data;
+ int ret = 0; /* Silence warning */
+
+ /*
+ * Make sure it's something we can do. User pointers could be
+ * implemented without great pain, but that's not been done yet.
+ */
+ if (req-memory != V4L2_MEMORY_MMAP)
+ return -EINVAL;
only MMAP ?
Yes, the current code doesn't do USERPTR, never has. The vb2 conversion
(already working in my tree here, BTW) will fix that.
+static int mcam_vidioc_qbuf(struct file *filp, void *priv,
+ struct v4l2_buffer *buf)
+{
+ struct mcam_camera *cam = filp-private_data;
+ struct mcam_sio_buffer *sbuf;
+ int ret = -EINVAL;
+ unsigned long flags;
+
+ mutex_lock(cam-s_mutex);
+ if (buf-index = cam-n_sbufs)
+ goto out;
+ sbuf = cam-sb_bufs + buf-index;
+ if (sbuf-v4lbuf.flags V4L2_BUF_FLAG_QUEUED) {
+ ret = 0; /* Already queued?? */
+ goto out
Re: [PATCH 8/8] marvell-cam: Basic working MMP camera driver
2011/6/12 Jonathan Corbet cor...@lwn.net:
Now we have a camera working over the marvell cam controller core. It
works like the cafe driver and has all the same limitations, contiguous DMA
only being one of them. But it's a start.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/Makefile | 1 +
drivers/media/video/marvell-ccic/Kconfig | 11 +
drivers/media/video/marvell-ccic/Makefile | 4 +
drivers/media/video/marvell-ccic/mcam-core.c | 28 ++-
drivers/media/video/marvell-ccic/mmp-driver.c | 339
+
include/media/mmp-camera.h | 9 +
include/media/v4l2-chip-ident.h | 3 +-
7 files changed, 386 insertions(+), 9 deletions(-)
create mode 100644 drivers/media/video/marvell-ccic/mmp-driver.c
create mode 100644 include/media/mmp-camera.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 42b6a7a..89478f0 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -128,6 +128,7 @@ obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o
obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
obj-$(CONFIG_VIDEO_CAFE_CCIC) += marvell-ccic/
+obj-$(CONFIG_VIDEO_MMP_CAMERA) += marvell-ccic/
obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
diff --git a/drivers/media/video/marvell-ccic/Kconfig
b/drivers/media/video/marvell-ccic/Kconfig
index 80136a8..b4f7260 100644
--- a/drivers/media/video/marvell-ccic/Kconfig
+++ b/drivers/media/video/marvell-ccic/Kconfig
@@ -7,3 +7,14 @@ config VIDEO_CAFE_CCIC
CMOS camera controller. This is the controller found on first-
generation OLPC systems.
+config VIDEO_MMP_CAMERA
+ tristate Marvell Armada 610 integrated camera controller support
+ depends on ARCH_MMP I2C VIDEO_V4L2
+ select VIDEO_OV7670
+ select I2C_GPIO
+ ---help---
+ This is a Video4Linux2 driver for the integrated camera
+ controller found on Marvell Armada 610 application
+ processors (and likely beyond). This is the controller found
+ in OLPC XO 1.75 systems.
+
diff --git a/drivers/media/video/marvell-ccic/Makefile
b/drivers/media/video/marvell-ccic/Makefile
index 462b385c..05a792c 100644
--- a/drivers/media/video/marvell-ccic/Makefile
+++ b/drivers/media/video/marvell-ccic/Makefile
@@ -1,2 +1,6 @@
obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o
cafe_ccic-y := cafe-driver.o mcam-core.o
+
+obj-$(CONFIG_VIDEO_MMP_CAMERA) += mmp_camera.o
+mmp_camera-y := mmp-driver.o mcam-core.o
+
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index 014b70b..3e6a5e8 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -167,7 +167,7 @@ static void mcam_set_config_needed(struct mcam_camera
*cam, int needed)
/*
- * Debugging and related. FIXME these are broken
+ * Debugging and related.
*/
#define cam_err(cam, fmt, arg...) \
dev_err((cam)-dev, fmt, ##arg);
@@ -202,7 +202,8 @@ static void mcam_ctlr_dma(struct mcam_camera *cam)
mcam_reg_clear_bit(cam, REG_CTRL1, C1_TWOBUFS);
} else
mcam_reg_set_bit(cam, REG_CTRL1, C1_TWOBUFS);
- mcam_reg_write(cam, REG_UBAR, 0); /* 32 bits only for now */
+ if (cam-chip_id == V4L2_IDENT_CAFE)
+ mcam_reg_write(cam, REG_UBAR, 0); /* 32 bits only */
}
static void mcam_ctlr_image(struct mcam_camera *cam)
@@ -358,8 +359,8 @@ static void mcam_ctlr_power_up(struct mcam_camera *cam)
unsigned long flags;
spin_lock_irqsave(cam-dev_lock, flags);
- mcam_reg_clear_bit(cam, REG_CTRL1, C1_PWRDWN);
cam-plat_power_up(cam);
+ mcam_reg_clear_bit(cam, REG_CTRL1, C1_PWRDWN);
spin_unlock_irqrestore(cam-dev_lock, flags);
msleep(5); /* Just to be sure */
}
@@ -369,8 +370,13 @@ static void mcam_ctlr_power_down(struct mcam_camera *cam)
unsigned long flags;
spin_lock_irqsave(cam-dev_lock, flags);
- cam-plat_power_down(cam);
+ /*
+ * School of hard knocks department: be sure we do any register
+ * twiddling on the controller *before* calling the platform
+ * power down routine.
+ */
mcam_reg_set_bit(cam, REG_CTRL1, C1_PWRDWN);
+ cam-plat_power_down(cam);
spin_unlock_irqrestore(cam-dev_lock, flags);
}
@@ -1622,14 +1628,20 @@ out_unregister:
void mccic_shutdown(struct mcam_camera *cam)
{
- if (cam-users 0)
+ /*
+ * If we have no users (and we really, really should have no
+ * users) the device will already be powered down. Trying to
+ * take it down again will wedge the machine, which is frowned
+ * upon.
+ */
+ if (cam-users 0) {
cam_warn(cam, Removing a device with users!\n);
+
Re: [PATCH 2/8] marvell-cam: Separate out the Marvell camera core
Jon:
after review your code:
1) here is the code, that deal with controller we can share.but
still need to tune.
2) for mcam_ctlr_stop_dma implementation, I guess you know
something about the silicon limitation, but we found it can not pass
our stress test(1000 times capture test, which will switch format
between JPEG and YUV again and again).
our solution is :
stop the ccic controller and wait for about one frame transfer
time, and the stop the sensor.
this passed our stress test. for your info.
3) for videoubuf2, will you use videoubuf2 only or combined
with soc-camera ? when can your driver for videoubuf2 ready ?
thanks, i am happy to verify on our PXA910, MMP2, MMP3 chip.
4) the point is: ccic and sensor driver should be independent,
and support two CCIC controller.
I've added the MMAP feature in my driver as you asked.
thank you very much!
/* --- */
+/*
+ * Deal with the controller.
+ */
+
+/*
+ * Do everything we think we need to have the interface operating
+ * according to the desired format.
+ */
+static void mcam_ctlr_dma(struct mcam_camera *cam)
+{
+ /*
+* Store the first two Y buffers (we aren't supporting
+* planar formats for now, so no UV bufs). Then either
+* set the third if it exists, or tell the controller
+* to just use two.
+*/
+ mcam_reg_write(cam, REG_Y0BAR, cam-dma_handles[0]);
+ mcam_reg_write(cam, REG_Y1BAR, cam-dma_handles[1]);
+ if (cam-nbufs 2) {
+ mcam_reg_write(cam, REG_Y2BAR, cam-dma_handles[2]);
+ mcam_reg_clear_bit(cam, REG_CTRL1, C1_TWOBUFS);
+ } else
+ mcam_reg_set_bit(cam, REG_CTRL1, C1_TWOBUFS);
+ mcam_reg_write(cam, REG_UBAR, 0); /* 32 bits only for now */
+}
+
+static void mcam_ctlr_image(struct mcam_camera *cam)
+{
+ int imgsz;
+ struct v4l2_pix_format *fmt = cam-pix_format;
+
+ imgsz = ((fmt-height IMGSZ_V_SHIFT) IMGSZ_V_MASK) |
+ (fmt-bytesperline IMGSZ_H_MASK);
+ mcam_reg_write(cam, REG_IMGSIZE, imgsz);
+ mcam_reg_write(cam, REG_IMGOFFSET, 0);
+ /* YPITCH just drops the last two bits */
+ mcam_reg_write_mask(cam, REG_IMGPITCH, fmt-bytesperline,
+ IMGP_YP_MASK);
+ /*
+* Tell the controller about the image format we are using.
+*/
+ switch (cam-pix_format.pixelformat) {
+ case V4L2_PIX_FMT_YUYV:
+ mcam_reg_write_mask(cam, REG_CTRL0,
+ C0_DF_YUV|C0_YUV_PACKED|C0_YUVE_YUYV,
+ C0_DF_MASK);
+ break;
+
+ case V4L2_PIX_FMT_RGB444:
+ mcam_reg_write_mask(cam, REG_CTRL0,
+ C0_DF_RGB|C0_RGBF_444|C0_RGB4_XRGB,
+ C0_DF_MASK);
+ /* Alpha value? */
+ break;
+
+ case V4L2_PIX_FMT_RGB565:
+ mcam_reg_write_mask(cam, REG_CTRL0,
+ C0_DF_RGB|C0_RGBF_565|C0_RGB5_BGGR,
+ C0_DF_MASK);
+ break;
+
+ default:
+ cam_err(cam, Unknown format %x\n, cam-pix_format.pixelformat);
+ break;
+ }
+ /*
+* Make sure it knows we want to use hsync/vsync.
+*/
+ mcam_reg_write_mask(cam, REG_CTRL0, C0_SIF_HVSYNC,
+ C0_SIFM_MASK);
+}
+
+
+/*
+ * Configure the controller for operation; caller holds the
+ * device mutex.
+ */
+static int mcam_ctlr_configure(struct mcam_camera *cam)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(cam-dev_lock, flags);
+ mcam_ctlr_dma(cam);
+ mcam_ctlr_image(cam);
+ mcam_set_config_needed(cam, 0);
+ spin_unlock_irqrestore(cam-dev_lock, flags);
+ return 0;
+}
+
+static void mcam_ctlr_irq_enable(struct mcam_camera *cam)
+{
+ /*
+* Clear any pending interrupts, since we do not
+* expect to have I/O active prior to enabling.
+*/
+ mcam_reg_write(cam, REG_IRQSTAT, FRAMEIRQS);
+ mcam_reg_set_bit(cam, REG_IRQMASK, FRAMEIRQS);
+}
+
+static void mcam_ctlr_irq_disable(struct mcam_camera *cam)
+{
+ mcam_reg_clear_bit(cam, REG_IRQMASK, FRAMEIRQS);
+}
+
+/*
+ * Make the controller start grabbing images. Everything must
+ * be set up before doing this.
+ */
+static void mcam_ctlr_start(struct mcam_camera *cam)
+{
+ /* set_bit performs a read, so no other barrier should be
+ needed here */
+ mcam_reg_set_bit(cam, REG_CTRL0, C0_ENABLE);
+}
+
+static void mcam_ctlr_stop(struct mcam_camera *cam)
+{
+ mcam_reg_clear_bit(cam, REG_CTRL0, C0_ENABLE);
+}
+
+static void mcam_ctlr_init(struct mcam_camera *cam)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(cam-dev_lock, flags);
+ /*
+* Make sure it's not powered down.
+*/
+ mcam_reg_clear_bit(cam, REG_CTRL1,
[PATCH] V4L/DVB: videobuf: mmap.prot checking for IN and OUT device
for OUTPUT device, it will map the page as VM_WRITE
and for INPUT device, it will map the page as
VM_READ. mmap will check the if the prot
is matched with the device type, but not only
check VM_WRITE.
This is actually synced from videobuf2.
Signed-off-by: Kassey Lee y...@marvell.com
hi, Guennadi:
how about sync this enhencement from videbuf2 to videbuf when MMAP is used ?
---
drivers/media/video/videobuf-core.c | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index de4fa4e..202dd5d 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -1182,10 +1182,24 @@ int videobuf_mmap_mapper(struct videobuf_queue *q,
struct vm_area_struct *vma)
MAGIC_CHECK(q-int_ops-magic, MAGIC_QTYPE_OPS);
- if (!(vma-vm_flags VM_WRITE) || !(vma-vm_flags VM_SHARED)) {
- dprintk(1, mmap appl bug: PROT_WRITE and MAP_SHARED are
required\n);
+ /*
+* Check memory area access mode.
+*/
+ if (!(vma-vm_flags VM_SHARED)) {
+ dprintk(1, Invalid vma flags, VM_SHARED needed\n);
return -EINVAL;
}
+ if (V4L2_TYPE_IS_OUTPUT(q-type)) {
+ if (!(vma-vm_flags VM_WRITE)) {
+ dprintk(1, Invalid vma flags, VM_WRITE needed\n);
+ return -EINVAL;
+ }
+ } else {
+ if (!(vma-vm_flags VM_READ)) {
+ dprintk(1, Invalid vma flags, VM_READ needed\n);
+ return -EINVAL;
+ }
+ }
videobuf_queue_lock(q);
for (i = 0; i VIDEO_MAX_FRAME; i++) {
--
1.7.4.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
Re: [PATCH 1/8] marvell-cam: Move cafe-ccic into its own directory
Jon, if you agree to change it in another patch, and now just to keep it with the driver that works for years. that is OK. thanks. I am looking forward your patch based on VB2, because based on current cafe_ccic.c, it is hard to share with my driver. 2011/6/14 Jonathan Corbet cor...@lwn.net: On Tue, 14 Jun 2011 10:23:58 +0800 Kassey Lee kassey1...@gmail.com wrote: Jon, Here is my comments. Thanks for having a look. +config VIDEO_CAFE_CCIC + tristate Marvell 88ALP01 (Cafe) CMOS Camera Controller support + depends on PCI I2C VIDEO_V4L2 + select VIDEO_OV7670 why need binds with sensor ? suppose CCIC driver and sensor driver are independent, even if your hardware only support OV7670 We all agree that needs to change. This particular patch, though, is concerned with moving a working driver into a new directory; making that sort of functional change would not be appropriate here. +#include media/ov7670.h ccic would not be aware of the sensor name. Ditto. Thanks, jon -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- 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/DVB: v4l: Add driver for Marvell PXA910 CCIC
On Fri, Jun 10, 2011 at 6:47 AM, Jonathan Corbet cor...@lwn.net wrote: Hi, Kassey, I've been looking at the driver some to understand how you're using the hardware. One quick question: The driver is based on soc-camera + videobuf2 frame work, and only USERPTR is supported. Since you're limited to contiguous DMA (does the PXA910 even support scatter/gather mode?), PXA910 supports scatter/gather mode, but we did not use that. USERPTR is going to be very limiting. Is the application mapping I/O memory elsewhere in the system with the expectation of having the video frames go directly there? Could you tell me how that works? I'd like to understand the use case here. USERPTR is popular on Android Camera HAL implementation.. we alloc memory in user space by PMEM, and QBUF to driver, once DMA finished the buffer, we DQBUF and send the buffer address to display DMA directly. or doing encode. MMAP can not offer big size memory, for 720P resolution, when running Android. FWIW, I believe that videobuf2 would support the MMAP mode with no additional effort on your part; any reason why you haven't enabled that? you are right. I just enabled it on videobuf, and I will try to enable it on videobuf2, too. thanks. Thanks, jon -- 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 -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- 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/DVB: v4l: Add driver for Marvell PXA910 CCIC
Guennadi, Jon: thanks! we hope to work out a common ccic core, and then re base the code. : On Wed, Jun 8, 2011 at 7:30 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Kassey Thanks for the new version, but, IIUC, you agreed to reimplement your driver on top of a common ccic core, which means, a lot of code will change. So, it doesn't really make much sense now to make and review new stand-alone versions of your driver, right? So, shall we wait until Jon's CCIC code stabilises a bit and you rebase your driver on top of it? Of course, you can also work together with Jon on the drivers to get them faster in shape and in a way, suitable fou you both. 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 -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- 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/DVB: v4l: Add driver for Marvell PXA910 CCIC
On Thu, Jun 9, 2011 at 4:42 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Thu, 9 Jun 2011, Kassey Lee wrote: Guennadi, Jon: thanks! we hope to work out a common ccic core, and then re base the code. ok, so, we agree, that I don't review your last version, ok? Guennadi, Jon your comments are always welcome and valuable for us. As Jon will convert cafe_ccic.c to videobuf2 too, I wish He can review this driver too, if it is useful for him. and find the common ccic core. Just Mark it. Thanks Thanks Guennadi : On Wed, Jun 8, 2011 at 7:30 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Kassey Thanks for the new version, but, IIUC, you agreed to reimplement your driver on top of a common ccic core, which means, a lot of code will change. So, it doesn't really make much sense now to make and review new stand-alone versions of your driver, right? So, shall we wait until Jon's CCIC code stabilises a bit and you rebase your driver on top of it? Of course, you can also work together with Jon on the drivers to get them faster in shape and in a way, suitable fou you both. 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 -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- 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] Refactor the cafe_ccic driver and add Armada 610 support
hi, Jon: thanks for your work! it is good to know that your brought up MMP2(610) SoC with OV7670 I have some questions: 1) this driver is still based on cafe_ccic.c, as you said, we can abstract the low level register function, and use soc_camera and videofbu2 to manage the buff and state machine, how do you think ? 2) i2c_adapter, how about move this code to driver/i2c, then ccic driver will become clean? 3) in mmp_driver.c, it has the sensor name, OV7670, we wish that ccic driver do not need to aware of the sensor, also we need to support front and back camera sensor cases. Guennadi, what is your suggestions ? great thanks! On Tue, Jun 7, 2011 at 6:39 AM, Jonathan Corbet cor...@lwn.net wrote: Hello, all, As I promised last week, here's the state of my work refactoring the Cafe driver and adding Armada 610 support. I intend to have them ready for 3.1, but they are not ready for merging yet. There's a couple of things I'd like to clean up, and I'd like to let the OLPC people test things a bit more. But I figured it would be good to get it out there for comments. Essentially, Marvell has taken the camera controller from the old Cafe chip and dropped it into some ARM SoC setups, one of which is the Armada 610. I pondered just making a new driver, but, given that the controller has changed very little, it made a lot more sense to reuse the existing code. The patches here split cafe_ccic.c into platform and core pieces while leaving functionality unchanged. The new mmp-camera driver is then added as a second platform. This work is not done; at a minimum, I plan to convert it over to videobuf2 and make use of the Armada's s/g DMA capabilities. Doubtless there is plenty more to be done; I would also sure like to see Kassey Lee's Marvell driver integrated with this one if at all possible. Comments? Thanks, jon -- 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 -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- 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] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
response for Guennadi comments.
thanks
On Tue, Jun 7, 2011 at 1:42 PM, Kassey Lee kassey1...@gmail.com wrote:
Guennadi
thanks for your comments very much! I will update the V3 patch
later.
On Fri, Jun 3, 2011 at 6:22 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Ok, this will be converted to use a common cafe code, but I'll comment
on this version anyway, for your future reference.
On Wed, 1 Jun 2011, Kassey Lee wrote:
This driver exports a video device node per each CCIC
(CMOS Camera Interface Controller)
device contained in Marvell Mobile PXA910 SoC
The driver is based on soc-camera + videobuf2 frame
work, and only USERPTR is supported.
Signed-off-by: Kassey Lee y...@marvell.com
---
arch/arm/mach-mmp/include/mach/camera.h | 37 ++
drivers/media/video/Kconfig | 7 +
drivers/media/video/Makefile | 1 +
drivers/media/video/mv_camera.c | 1067
+++
4 files changed, 1112 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
create mode 100644 drivers/media/video/mv_camera.c
diff --git a/arch/arm/mach-mmp/include/mach/camera.h
b/arch/arm/mach-mmp/include/mach/camera.h
new file mode 100644
index 000..ff8cde1
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/camera.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.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.
+ *
+ */
+
+#ifndef __ASM_ARCH_CAMERA_H__
+#define __ASM_ARCH_CAMERA_H__
+
+#define MV_CAMERA_MASTER 1
+#define MV_CAMERA_DATAWIDTH_8 8
+#define MV_CAMERA_DATAWIDTH_10 0x20
+#define MV_CAMERA_PCLK_EN 0x40
+#define MV_CAMERA_MCLK_EN 0x80
+#define MV_CAMERA_PCP 0x100
+#define MV_CAMERA_HSP 0x200
+#define MV_CAMERA_VSP 0x400
+
+struct mv_cam_pdata {
+ int dphy[3];
+ unsigned long flags;
+ int dma_burst;
+ int mclk_min;
+ int mclk_src;
+ int (*init_clk) (struct device *dev, int init);
+ void (*enable_clk) (struct device *dev, int on);
+ int (*get_mclk_src) (int src);
+};
+
+#endif
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 3be180b..18ab3a5 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -891,6 +891,13 @@ config VIDEO_MX3
---help---
This is a v4l2 driver for the i.MX3x Camera Sensor Interface
+config VIDEO_MV_CCIC
+ tristate Marvell CMOS Camera Interface Controller driver
+ depends on VIDEO_DEV CPU_PXA910 SOC_CAMERA
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This is a v4l2 driver for the Marvell CCIC Interface
+
config VIDEO_PXA27x
tristate PXA27x Quick Capture Interface driver
depends on VIDEO_DEV PXA27x SOC_CAMERA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 9519160..e3251c3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) +=
soc_camera_platform.o
obj-$(CONFIG_VIDEO_MX1) += mx1_camera.o
obj-$(CONFIG_VIDEO_MX2) += mx2_camera.o
obj-$(CONFIG_VIDEO_MX3) += mx3_camera.o
+obj-$(CONFIG_VIDEO_MV_CCIC) += mv_camera.o
Ok, I still _think_, mv_camera is too generic a name for this driver,
but it's up to you, really, just my thought.
we has mv_gadget(usb), that is Marvell's preferred name. thanks
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o
diff --git a/drivers/media/video/mv_camera.c
b/drivers/media/video/mv_camera.c
new file mode 100644
index 000..f19c43d
--- /dev/null
+++ b/drivers/media/video/mv_camera.c
@@ -0,0 +1,1067 @@
+/*
+ * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
+ * (CMOS Capture Interface Controller)
+ *
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.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.
+ *
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/dma-mapping.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/io.h
Re: [PATCH V2] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
Guennadi
thanks for your comments very much! I will update the V3 patch later.
On Fri, Jun 3, 2011 at 6:22 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Ok, this will be converted to use a common cafe code, but I'll comment
on this version anyway, for your future reference.
On Wed, 1 Jun 2011, Kassey Lee wrote:
This driver exports a video device node per each CCIC
(CMOS Camera Interface Controller)
device contained in Marvell Mobile PXA910 SoC
The driver is based on soc-camera + videobuf2 frame
work, and only USERPTR is supported.
Signed-off-by: Kassey Lee y...@marvell.com
---
arch/arm/mach-mmp/include/mach/camera.h | 37 ++
drivers/media/video/Kconfig | 7 +
drivers/media/video/Makefile | 1 +
drivers/media/video/mv_camera.c | 1067
+++
4 files changed, 1112 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
create mode 100644 drivers/media/video/mv_camera.c
diff --git a/arch/arm/mach-mmp/include/mach/camera.h
b/arch/arm/mach-mmp/include/mach/camera.h
new file mode 100644
index 000..ff8cde1
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/camera.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.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.
+ *
+ */
+
+#ifndef __ASM_ARCH_CAMERA_H__
+#define __ASM_ARCH_CAMERA_H__
+
+#define MV_CAMERA_MASTER 1
+#define MV_CAMERA_DATAWIDTH_8 8
+#define MV_CAMERA_DATAWIDTH_10 0x20
+#define MV_CAMERA_PCLK_EN 0x40
+#define MV_CAMERA_MCLK_EN 0x80
+#define MV_CAMERA_PCP 0x100
+#define MV_CAMERA_HSP 0x200
+#define MV_CAMERA_VSP 0x400
+
+struct mv_cam_pdata {
+ int dphy[3];
+ unsigned long flags;
+ int dma_burst;
+ int mclk_min;
+ int mclk_src;
+ int (*init_clk) (struct device *dev, int init);
+ void (*enable_clk) (struct device *dev, int on);
+ int (*get_mclk_src) (int src);
+};
+
+#endif
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 3be180b..18ab3a5 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -891,6 +891,13 @@ config VIDEO_MX3
---help---
This is a v4l2 driver for the i.MX3x Camera Sensor Interface
+config VIDEO_MV_CCIC
+ tristate Marvell CMOS Camera Interface Controller driver
+ depends on VIDEO_DEV CPU_PXA910 SOC_CAMERA
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This is a v4l2 driver for the Marvell CCIC Interface
+
config VIDEO_PXA27x
tristate PXA27x Quick Capture Interface driver
depends on VIDEO_DEV PXA27x SOC_CAMERA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 9519160..e3251c3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) +=
soc_camera_platform.o
obj-$(CONFIG_VIDEO_MX1) += mx1_camera.o
obj-$(CONFIG_VIDEO_MX2) += mx2_camera.o
obj-$(CONFIG_VIDEO_MX3) += mx3_camera.o
+obj-$(CONFIG_VIDEO_MV_CCIC) += mv_camera.o
Ok, I still _think_, mv_camera is too generic a name for this driver,
but it's up to you, really, just my thought.
we has mv_gadget(usb), that is Marvell's preferred name. thanks
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o
diff --git a/drivers/media/video/mv_camera.c
b/drivers/media/video/mv_camera.c
new file mode 100644
index 000..f19c43d
--- /dev/null
+++ b/drivers/media/video/mv_camera.c
@@ -0,0 +1,1067 @@
+/*
+ * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
+ * (CMOS Capture Interface Controller)
+ *
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.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.
+ *
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/dma-mapping.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/module.h
+#include linux/platform_device.h
+#include
Re: [RFC] Refactor the cafe_ccic driver and add Armada 610 support
Hi, Jon: for PXA910, MMP2(Armda 610) actually, CCIC are almost the same. but MMP2 has 2 CCIC controllers, and PXA910 only has 1 CCIC controller. so it is quite make your driver works on MMP2 and PXA910. On Tue, Jun 7, 2011 at 9:45 PM, Jonathan Corbet cor...@lwn.net wrote: On Tue, 7 Jun 2011 13:30:11 +0800 Kassey Lee kassey1...@gmail.com wrote: 1) this driver is still based on cafe_ccic.c, as you said, we can abstract the low level register function, and use soc_camera and videofbu2 to manage the buff and state machine, how do you think ? As I said, videobuf2 is on my list of things to do. Note that the driver works just fine without - that code has been in the kernel and working for years. But it's a cleanup that needs to be done at this point, and I will do it. Since we have converted a videfbuf2 version for PXA910, could you have time to review ? and find the common part to make a better one works on cafe-ccic, PXA910, and MMP2 ? it takes quite time to convert from cafe-ccic.c to videfbuf2 for me. 2) i2c_adapter, how about move this code to driver/i2c, then ccic driver will become clean? The problem there is that you can't easily disentangle the two devices - they use the same registers, the same IRQ line, etc. One *could* turn the whole thing into an MFD driver and split them apart, but I honestly don't see a reason to do that. I'd be surprised if a Cafe chip ever shows up in anything new these days, so it's only used in the OLPC XO 1, and that i2c will never be used for anything but the sensor. The i2c *has* been abstracted out of the camera core, so the Cafe i2c implementation will not get in the way of any new drivers. for cafe i2c, it is OK. but for PXA910 and MMP2, the i2c adapter is out of CCIC. 3) in mmp_driver.c, it has the sensor name, OV7670, we wish that ccic driver do not need to aware of the sensor, also we need to support front and back camera sensor cases. The only reason the ov7670 dependency is there is because that's the only sensor the driver has ever been used with. Adding other sensors has been complicated a bit by Hans's changes which pushed awareness of the available video formats into the controller driver (I complained at the time), but that can be worked around. For front and back: I didn't wire up the second controller in the mmp driver because I don't have a device that uses both. I very much wrote the driver with the idea that both controllers could be used, though; finishing that job will be easy. sorry for confusion, we have another case: one CCIC should work with two sensors, and switch them by need. what i mean, for CCIC driver it should not aware the sensor, it can be done by user application. One thing I haven't done is to look at your driver closely enough to think about whether mmp_camera can drive your hardware or not. You'll have a better idea of that than me, I suspect; is the hardware pretty much the same? I will update my driver again after Guennadi's comments, would you please have time to review ? 1) add Jon's email, and cafe-ccic.c copyright. 2) set_bus_param check for HSYNC, PCLK 3) code stye fix. Thanks, jon -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- 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 V3] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
This driver exports a video device node per each CCIC
(CMOS Camera Interface Controller)
device contained in Marvell Mobile PXA910 SoC
The driver is based on soc-camera + videobuf2 frame
work, and only USERPTR is supported.
Signed-off-by: Kassey Lee y...@marvell.com
---
arch/arm/mach-mmp/include/mach/camera.h | 37 ++
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile|1 +
drivers/media/video/mv_camera.c | 1071 +++
4 files changed, 1116 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
create mode 100644 drivers/media/video/mv_camera.c
diff --git a/arch/arm/mach-mmp/include/mach/camera.h
b/arch/arm/mach-mmp/include/mach/camera.h
new file mode 100644
index 000..ff8cde1
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/camera.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.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.
+ *
+ */
+
+#ifndef __ASM_ARCH_CAMERA_H__
+#define __ASM_ARCH_CAMERA_H__
+
+#define MV_CAMERA_MASTER 1
+#define MV_CAMERA_DATAWIDTH_8 8
+#define MV_CAMERA_DATAWIDTH_10 0x20
+#define MV_CAMERA_PCLK_EN 0x40
+#define MV_CAMERA_MCLK_EN 0x80
+#define MV_CAMERA_PCP 0x100
+#define MV_CAMERA_HSP 0x200
+#define MV_CAMERA_VSP 0x400
+
+struct mv_cam_pdata {
+ int dphy[3];
+ unsigned long flags;
+ int dma_burst;
+ int mclk_min;
+ int mclk_src;
+ int (*init_clk) (struct device *dev, int init);
+ void (*enable_clk) (struct device *dev, int on);
+ int (*get_mclk_src) (int src);
+};
+
+#endif
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 3be180b..18ab3a5 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -891,6 +891,13 @@ config VIDEO_MX3
---help---
This is a v4l2 driver for the i.MX3x Camera Sensor Interface
+config VIDEO_MV_CCIC
+ tristate Marvell CMOS Camera Interface Controller driver
+ depends on VIDEO_DEV CPU_PXA910 SOC_CAMERA
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This is a v4l2 driver for the Marvell CCIC Interface
+
config VIDEO_PXA27x
tristate PXA27x Quick Capture Interface driver
depends on VIDEO_DEV PXA27x SOC_CAMERA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 9519160..e3251c3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o
obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
+obj-$(CONFIG_VIDEO_MV_CCIC)+= mv_camera.o
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o
diff --git a/drivers/media/video/mv_camera.c b/drivers/media/video/mv_camera.c
new file mode 100644
index 000..ed2397f
--- /dev/null
+++ b/drivers/media/video/mv_camera.c
@@ -0,0 +1,1071 @@
+/*
+ * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
+ * (CMOS Capture Interface Controller)
+ *
+ * This driver is based on soc_camera and videobuf2
+ * framework, but part of the low level register function
+ * is base on cafe_ccic.c
+ *
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.com
+ *
+ * Copyright 2006 One Laptop Per Child Association, Inc.
+ * Copyright 2006-7 Jonathan Corbet cor...@lwn.net
+ *
+ * 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.
+ *
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/dma-mapping.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/time.h
+#include linux/videodev2.h
+
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+#include media/v4l2-common.h
+#include media/v4l2-dev.h
+#include media/videobuf2-dma-contig.h
+
+#include mach/camera.h
+#include cafe_ccic-regs.h
+
+/* Register definition for PXA910 */
+
+#define REG_U0BAR
[PATCH] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
This driver exports a video device node per each CCIC
(CMOS Camera Interface Controller)
device contained in Marvell Mobile PXA910 SoC
The driver is based on soc-camera + videobuf2 frame
work, and only USERPTR is supported.
Signed-off-by: Kassey Lee y...@marvell.com
---
arch/arm/mach-mmp/include/mach/camera.h | 37 ++
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile|1 +
drivers/media/video/mv_camera.c | 1071 +++
4 files changed, 1116 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
create mode 100644 drivers/media/video/mv_camera.c
V3 Changes:
1) add cafe-ccic copyright
2) add VSYNC, HSYNC, PCLK check for CCIC
3) code style fix as Guennadi's comments
diff --git a/arch/arm/mach-mmp/include/mach/camera.h
b/arch/arm/mach-mmp/include/mach/camera.h
new file mode 100644
index 000..ff8cde1
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/camera.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.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.
+ *
+ */
+
+#ifndef __ASM_ARCH_CAMERA_H__
+#define __ASM_ARCH_CAMERA_H__
+
+#define MV_CAMERA_MASTER 1
+#define MV_CAMERA_DATAWIDTH_8 8
+#define MV_CAMERA_DATAWIDTH_10 0x20
+#define MV_CAMERA_PCLK_EN 0x40
+#define MV_CAMERA_MCLK_EN 0x80
+#define MV_CAMERA_PCP 0x100
+#define MV_CAMERA_HSP 0x200
+#define MV_CAMERA_VSP 0x400
+
+struct mv_cam_pdata {
+ int dphy[3];
+ unsigned long flags;
+ int dma_burst;
+ int mclk_min;
+ int mclk_src;
+ int (*init_clk) (struct device *dev, int init);
+ void (*enable_clk) (struct device *dev, int on);
+ int (*get_mclk_src) (int src);
+};
+
+#endif
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 3be180b..18ab3a5 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -891,6 +891,13 @@ config VIDEO_MX3
---help---
This is a v4l2 driver for the i.MX3x Camera Sensor Interface
+config VIDEO_MV_CCIC
+ tristate Marvell CMOS Camera Interface Controller driver
+ depends on VIDEO_DEV CPU_PXA910 SOC_CAMERA
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This is a v4l2 driver for the Marvell CCIC Interface
+
config VIDEO_PXA27x
tristate PXA27x Quick Capture Interface driver
depends on VIDEO_DEV PXA27x SOC_CAMERA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 9519160..e3251c3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o
obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
+obj-$(CONFIG_VIDEO_MV_CCIC)+= mv_camera.o
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o
diff --git a/drivers/media/video/mv_camera.c b/drivers/media/video/mv_camera.c
new file mode 100644
index 000..3a03a40
--- /dev/null
+++ b/drivers/media/video/mv_camera.c
@@ -0,0 +1,1071 @@
+/*
+ * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
+ * (CMOS Capture Interface Controller)
+ *
+ * This driver is based on soc_camera and videobuf2
+ * framework, but part of the low level register function
+ * is base on cafe_ccic.c
+ *
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.com
+ *
+ * Copyright 2006 One Laptop Per Child Association, Inc.
+ * Copyright 2006-7 Jonathan Corbet cor...@lwn.net
+ *
+ * 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.
+ *
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/dma-mapping.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/time.h
+#include linux/videodev2.h
+
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+#include media/v4l2-common.h
+#include media/v4l2-dev.h
+#include media/videobuf2-dma
Re: [PATCH] V4L: soc-camera: MIPI flags are not sensor flags
hi, Guennadi:
I'm a little confused.
there is possible that a board will connect the sensor with
[1234] lanes.
so this means it could be a board-specific flags too ?
thanks!
Best regards
Kassey
Application Processor Systems Engineering, Marvell Technology Group Ltd.
Shanghai, China.
On Tue, Jun 7, 2011 at 1:17 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
SOCAM_MIPI_[1234]LANE flags are not board-specific sensor flags, they
are bus configuration flags.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
include/media/soc_camera.h | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 238bd33..e34b5e6 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -109,12 +109,6 @@ struct soc_camera_host_ops {
#define SOCAM_SENSOR_INVERT_HSYNC (1 2)
#define SOCAM_SENSOR_INVERT_VSYNC (1 3)
#define SOCAM_SENSOR_INVERT_DATA (1 4)
-#define SOCAM_MIPI_1LANE (1 5)
-#define SOCAM_MIPI_2LANE (1 6)
-#define SOCAM_MIPI_3LANE (1 7)
-#define SOCAM_MIPI_4LANE (1 8)
-#define SOCAM_MIPI (SOCAM_MIPI_1LANE | SOCAM_MIPI_2LANE | \
- SOCAM_MIPI_3LANE | SOCAM_MIPI_4LANE)
struct i2c_board_info;
struct regulator_bulk_data;
@@ -270,6 +264,12 @@ static inline struct v4l2_queryctrl const
*soc_camera_find_qctrl(
#define SOCAM_PCLK_SAMPLE_FALLING (1 13)
#define SOCAM_DATA_ACTIVE_HIGH (1 14)
#define SOCAM_DATA_ACTIVE_LOW (1 15)
+#define SOCAM_MIPI_1LANE (1 16)
+#define SOCAM_MIPI_2LANE (1 17)
+#define SOCAM_MIPI_3LANE (1 18)
+#define SOCAM_MIPI_4LANE (1 19)
+#define SOCAM_MIPI (SOCAM_MIPI_1LANE | SOCAM_MIPI_2LANE | \
+ SOCAM_MIPI_3LANE | SOCAM_MIPI_4LANE)
#define SOCAM_DATAWIDTH_MASK (SOCAM_DATAWIDTH_4 | SOCAM_DATAWIDTH_8 | \
SOCAM_DATAWIDTH_9 | SOCAM_DATAWIDTH_10 | \
--
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
--
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] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
hi, Jonathan: yes, you are right, this driver uses most of the low level code from cafe-ccic.c. I am so sorry to miss the your email and refer info from cafe-ccic.c in my driver, really appreciate your work. the point that I write mv_camera.c is to base the soc_camera + vidieobuf2, other than manage the buffer by our-self which is done in cafe-ccic.c. I am OK to wait for your work on Armada 610, is this based on soc_camera + videobuf2 ? let's make it a more graceful driver. thanks On Thu, Jun 2, 2011 at 5:24 PM, Jonathan Corbet cor...@lwn.net wrote: On Wed, 1 Jun 2011 21:16:45 +0800 Kassey Lee y...@marvell.com wrote: This driver exports a video device node per each CCIC (CMOS Camera Interface Controller) device contained in Marvell Mobile PXA910 SoC The driver is based on soc-camera + videobuf2 frame work, and only USERPTR is supported. This device looks awfully similar to the Cafe controller; you must certainly have known that, since some of the code in your driver is clearly copied (without attribution) from cafe_ccic.c. As it happens, I've just written a driver for the Armada 610 SoC found in the OLPC 1.75 system; I was planning to post it as early as next week. I took a different approach, though: rather than duplicating the Cafe code, I split that driver into core and platform parts, then added a new platform piece for the Armada 610. I do believe that is a better way of doing things. That said, your driver has useful stuff that mine doesn't - MIPI support, for example. I'm traveling, but will be back next week. I'll send out my work after that; then I would really like to find a way to make all these pieces work together with a common core for cafe-derived controllers. Make sense? Thanks, jon -- 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] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
Guennadi:
thanks for your detail review and comments.
I updated one by one, and will send out the patch later.
thanks
2011/5/31 Guennadi Liakhovetski g.liakhovet...@gmx.de:
On Fri, 27 May 2011, Kassey Lee wrote:
This driver exports a video device node per each CCIC
(CMOS Camera Interface Controller)
device contained in Marvell Mobile PXA910 SoC
The driver is based on v4l2-mem2mem framework, and only
What does it have to do with mem2mem?
[kassey] sorry, I will change it to this driver is based on soc-camera and
videobuf2 framework
USERPTR is supported.
Signed-off-by: Kassey Lee y...@marvell.com
---
arch/arm/mach-mmp/include/mach/camera.h | 33 +
drivers/media/video/Kconfig | 7 +
drivers/media/video/Makefile | 1 +
drivers/media/video/mv_camera.c | 1120
+++
4 files changed, 1161 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
create mode 100644 drivers/media/video/mv_camera.c
diff --git a/arch/arm/mach-mmp/include/mach/camera.h
b/arch/arm/mach-mmp/include/mach/camera.h
new file mode 100644
index 000..b008f3f
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/camera.h
@@ -0,0 +1,33 @@
+/*
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.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.
+ *
+ */
+
+#ifndef __ASM_ARCH_CAMERA_H__
+#define __ASM_ARCH_CAMERA_H__
+
+#define MAX_CAM_CLK 3
+struct mv_cam_pdata {
+ struct clk *clk[MAX_CAM_CLK];
+ char *name;
+ int clk_enabled;
None of the above fields seem to be used
[kassey] OK, i will remove them.
+ int dphy[3];
+ int bus_type;
Hm, you're running a bit ahead of time with this one;) SOCAM_MIPI is _not_
a bus-type, but yes, I'm thinking about adding a bus_type field to struct
soc_camera_device, in fact, I've been doing that just a couple of hours
before reviewing this code:) So far I forsee having 3 bus-types: normal
PARALLEL, BT656 and MIPI_CSI2, sounds reasonable? Even though I don't
think we explicitly support BT656 anywhere in soc-camera yet.
[kassey]appreciate your patch for the bus_type, for now, how about change it
to flags, where the platform will define the but attribute that this board
supports ?
+ int dma_burst;
+ int qos_req_min;
Unused?
[kassey] qos_req_min removed.
+ int mclk_min;
+ int mclk_src;
+ int (*clk_init) (struct device *dev, int init);
+ void (*set_clock) (struct device *dev, int on);
+ int (*get_mclk_src) (int src);
+};
+
+#endif
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 3be180b..3b7a70e 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -891,6 +891,13 @@ config VIDEO_MX3
---help---
This is a v4l2 driver for the i.MX3x Camera Sensor Interface
+config VIDEO_MV
Maybe choose a more specific name? Either with CCIC or with PXA910 in it -
whatever you feel is more appropriate. Same holds for the filename and,
ideally, for the whole used namespace. We hope this is not the last V4L2
driver from Marvell:-)
[kassey] OK, how aboutVIDEO_MV_CCIC ?
+ tristate Marvell CMOS Camera Interface Controller driver
+ depends on VIDEO_DEV CPU_PXA910 SOC_CAMERA
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This is a v4l2 driver for the Marvell CCIC Interface
+
config VIDEO_PXA27x
tristate PXA27x Quick Capture Interface driver
depends on VIDEO_DEV PXA27x SOC_CAMERA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 9519160..373b706 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) +=
soc_camera_platform.o
obj-$(CONFIG_VIDEO_MX1) += mx1_camera.o
obj-$(CONFIG_VIDEO_MX2) += mx2_camera.o
obj-$(CONFIG_VIDEO_MX3) += mx3_camera.o
+obj-$(CONFIG_VIDEO_MV) += mv_camera.o
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o
diff --git a/drivers/media/video/mv_camera.c
b/drivers/media/video/mv_camera.c
new file mode 100644
index 000..1a8f73e
--- /dev/null
+++ b/drivers/media/video/mv_camera.c
@@ -0,0 +1,1120 @@
+/*
+ * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
+ * (CMOS Capture Interface Controller)
+ *
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
[PATCH V2] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
This driver exports a video device node per each CCIC
(CMOS Camera Interface Controller)
device contained in Marvell Mobile PXA910 SoC
The driver is based on soc-camera + videobuf2 frame
work, and only USERPTR is supported.
Signed-off-by: Kassey Lee y...@marvell.com
---
arch/arm/mach-mmp/include/mach/camera.h | 37 ++
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile|1 +
drivers/media/video/mv_camera.c | 1067 +++
4 files changed, 1112 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
create mode 100644 drivers/media/video/mv_camera.c
diff --git a/arch/arm/mach-mmp/include/mach/camera.h
b/arch/arm/mach-mmp/include/mach/camera.h
new file mode 100644
index 000..ff8cde1
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/camera.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.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.
+ *
+ */
+
+#ifndef __ASM_ARCH_CAMERA_H__
+#define __ASM_ARCH_CAMERA_H__
+
+#define MV_CAMERA_MASTER 1
+#define MV_CAMERA_DATAWIDTH_8 8
+#define MV_CAMERA_DATAWIDTH_10 0x20
+#define MV_CAMERA_PCLK_EN 0x40
+#define MV_CAMERA_MCLK_EN 0x80
+#define MV_CAMERA_PCP 0x100
+#define MV_CAMERA_HSP 0x200
+#define MV_CAMERA_VSP 0x400
+
+struct mv_cam_pdata {
+ int dphy[3];
+ unsigned long flags;
+ int dma_burst;
+ int mclk_min;
+ int mclk_src;
+ int (*init_clk) (struct device *dev, int init);
+ void (*enable_clk) (struct device *dev, int on);
+ int (*get_mclk_src) (int src);
+};
+
+#endif
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 3be180b..18ab3a5 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -891,6 +891,13 @@ config VIDEO_MX3
---help---
This is a v4l2 driver for the i.MX3x Camera Sensor Interface
+config VIDEO_MV_CCIC
+ tristate Marvell CMOS Camera Interface Controller driver
+ depends on VIDEO_DEV CPU_PXA910 SOC_CAMERA
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This is a v4l2 driver for the Marvell CCIC Interface
+
config VIDEO_PXA27x
tristate PXA27x Quick Capture Interface driver
depends on VIDEO_DEV PXA27x SOC_CAMERA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 9519160..e3251c3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o
obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
+obj-$(CONFIG_VIDEO_MV_CCIC)+= mv_camera.o
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o
diff --git a/drivers/media/video/mv_camera.c b/drivers/media/video/mv_camera.c
new file mode 100644
index 000..f19c43d
--- /dev/null
+++ b/drivers/media/video/mv_camera.c
@@ -0,0 +1,1067 @@
+/*
+ * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
+ * (CMOS Capture Interface Controller)
+ *
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.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.
+ *
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/dma-mapping.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/time.h
+#include linux/videodev2.h
+
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+#include media/v4l2-common.h
+#include media/v4l2-dev.h
+#include media/videobuf2-dma-contig.h
+
+#include mach/camera.h
+#include cafe_ccic-regs.h
+
+/* Register definition for PXA910 */
+
+#define REG_U0BAR 0x0c
+#define REG_U1BAR 0x10
+#define REG_U2BAR 0x14
+#define REG_V0BAR 0x18
+#define REG_V1BAR 0x1C
+#define REG_V2BAR 0x20
+
+/* for MIPI enable */
+#define REG_CSI2_CTRL0 0x100
+#define REG_CSI2_DPHY0 0x120
+#define
Re: [PATCH] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
This patch is to enable Marvell Mobile SoC PXA910 CMOS Cmera Interface
Controller driver support.
- Using soc-camera framework with videobuf2 dma-contig allocator
- Supporting video streaming of YUV packed format
- Tested on PXA910 TTC_DKB board with OV5642
hi, Guennadi, Hans,
as you suggested to prefer improved videobuf2, we converted
the Marvell SoC PXA910 CCIC driver from videobuf to videobuf2, and
verified OK. would you please help to review ?
thanks!
2011/5/27 Kassey Lee y...@marvell.com:
This driver exports a video device node per each CCIC
(CMOS Camera Interface Controller)
device contained in Marvell Mobile PXA910 SoC
The driver is based on v4l2-mem2mem framework, and only
USERPTR is supported.
Signed-off-by: Kassey Lee y...@marvell.com
---
arch/arm/mach-mmp/include/mach/camera.h | 33 +
drivers/media/video/Kconfig | 7 +
drivers/media/video/Makefile | 1 +
drivers/media/video/mv_camera.c | 1120
+++
4 files changed, 1161 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
create mode 100644 drivers/media/video/mv_camera.c
diff --git a/arch/arm/mach-mmp/include/mach/camera.h
b/arch/arm/mach-mmp/include/mach/camera.h
new file mode 100644
index 000..b008f3f
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/camera.h
@@ -0,0 +1,33 @@
+/*
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.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.
+ *
+ */
+
+#ifndef __ASM_ARCH_CAMERA_H__
+#define __ASM_ARCH_CAMERA_H__
+
+#define MAX_CAM_CLK 3
+struct mv_cam_pdata {
+ struct clk *clk[MAX_CAM_CLK];
+ char *name;
+ int clk_enabled;
+ int dphy[3];
+ int bus_type;
+ int dma_burst;
+ int qos_req_min;
+ int mclk_min;
+ int mclk_src;
+ int (*clk_init) (struct device *dev, int init);
+ void (*set_clock) (struct device *dev, int on);
+ int (*get_mclk_src) (int src);
+};
+
+#endif
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 3be180b..3b7a70e 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -891,6 +891,13 @@ config VIDEO_MX3
---help---
This is a v4l2 driver for the i.MX3x Camera Sensor Interface
+config VIDEO_MV
+ tristate Marvell CMOS Camera Interface Controller driver
+ depends on VIDEO_DEV CPU_PXA910 SOC_CAMERA
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This is a v4l2 driver for the Marvell CCIC Interface
+
config VIDEO_PXA27x
tristate PXA27x Quick Capture Interface driver
depends on VIDEO_DEV PXA27x SOC_CAMERA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 9519160..373b706 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) +=
soc_camera_platform.o
obj-$(CONFIG_VIDEO_MX1) += mx1_camera.o
obj-$(CONFIG_VIDEO_MX2) += mx2_camera.o
obj-$(CONFIG_VIDEO_MX3) += mx3_camera.o
+obj-$(CONFIG_VIDEO_MV) += mv_camera.o
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o
diff --git a/drivers/media/video/mv_camera.c b/drivers/media/video/mv_camera.c
new file mode 100644
index 000..1a8f73e
--- /dev/null
+++ b/drivers/media/video/mv_camera.c
@@ -0,0 +1,1120 @@
+/*
+ * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
+ * (CMOS Capture Interface Controller)
+ *
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.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.
+ *
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/io.h
+#include linux/delay.h
+#include linux/dma-mapping.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/time.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/slab.h
+#include linux/videodev2.h
+
+#include media/v4l2-common.h
+#include media/v4l2-dev.h
+#include
Re: [PATCH] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
thanks for your time.
2011/5/30 Guennadi Liakhovetski g.liakhovet...@gmx.de:
Hi
On Mon, 30 May 2011, Kassey Lee wrote:
This patch is to enable Marvell Mobile SoC PXA910 CMOS Cmera Interface
Controller driver support.
- Using soc-camera framework with videobuf2 dma-contig allocator
- Supporting video streaming of YUV packed format
- Tested on PXA910 TTC_DKB board with OV5642
hi, Guennadi, Hans,
as you suggested to prefer improved videobuf2, we converted
the Marvell SoC PXA910 CCIC driver from videobuf to videobuf2, and
verified OK. would you please help to review ?
thanks!
Review is in work, will try to finish it within the next couple of days.
Thanks
Guennadi
2011/5/27 Kassey Lee y...@marvell.com:
This driver exports a video device node per each CCIC
(CMOS Camera Interface Controller)
device contained in Marvell Mobile PXA910 SoC
The driver is based on v4l2-mem2mem framework, and only
USERPTR is supported.
Signed-off-by: Kassey Lee y...@marvell.com
---
arch/arm/mach-mmp/include/mach/camera.h | 33 +
drivers/media/video/Kconfig | 7 +
drivers/media/video/Makefile | 1 +
drivers/media/video/mv_camera.c | 1120
+++
4 files changed, 1161 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
create mode 100644 drivers/media/video/mv_camera.c
diff --git a/arch/arm/mach-mmp/include/mach/camera.h
b/arch/arm/mach-mmp/include/mach/camera.h
new file mode 100644
index 000..b008f3f
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/camera.h
@@ -0,0 +1,33 @@
+/*
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.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.
+ *
+ */
+
+#ifndef __ASM_ARCH_CAMERA_H__
+#define __ASM_ARCH_CAMERA_H__
+
+#define MAX_CAM_CLK 3
+struct mv_cam_pdata {
+ struct clk *clk[MAX_CAM_CLK];
+ char *name;
+ int clk_enabled;
+ int dphy[3];
+ int bus_type;
+ int dma_burst;
+ int qos_req_min;
+ int mclk_min;
+ int mclk_src;
+ int (*clk_init) (struct device *dev, int init);
+ void (*set_clock) (struct device *dev, int on);
+ int (*get_mclk_src) (int src);
+};
+
+#endif
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 3be180b..3b7a70e 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -891,6 +891,13 @@ config VIDEO_MX3
---help---
This is a v4l2 driver for the i.MX3x Camera Sensor Interface
+config VIDEO_MV
+ tristate Marvell CMOS Camera Interface Controller driver
+ depends on VIDEO_DEV CPU_PXA910 SOC_CAMERA
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This is a v4l2 driver for the Marvell CCIC Interface
+
config VIDEO_PXA27x
tristate PXA27x Quick Capture Interface driver
depends on VIDEO_DEV PXA27x SOC_CAMERA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 9519160..373b706 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) +=
soc_camera_platform.o
obj-$(CONFIG_VIDEO_MX1) += mx1_camera.o
obj-$(CONFIG_VIDEO_MX2) += mx2_camera.o
obj-$(CONFIG_VIDEO_MX3) += mx3_camera.o
+obj-$(CONFIG_VIDEO_MV) += mv_camera.o
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o
diff --git a/drivers/media/video/mv_camera.c
b/drivers/media/video/mv_camera.c
new file mode 100644
index 000..1a8f73e
--- /dev/null
+++ b/drivers/media/video/mv_camera.c
@@ -0,0 +1,1120 @@
+/*
+ * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
+ * (CMOS Capture Interface Controller)
+ *
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.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.
+ *
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/io.h
+#include linux/delay.h
+#include linux/dma-mapping.h
[PATCH] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
This driver exports a video device node per each CCIC
(CMOS Camera Interface Controller)
device contained in Marvell Mobile PXA910 SoC
The driver is based on v4l2-mem2mem framework, and only
USERPTR is supported.
Signed-off-by: Kassey Lee y...@marvell.com
---
arch/arm/mach-mmp/include/mach/camera.h | 33 +
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile|1 +
drivers/media/video/mv_camera.c | 1120 +++
4 files changed, 1161 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
create mode 100644 drivers/media/video/mv_camera.c
diff --git a/arch/arm/mach-mmp/include/mach/camera.h
b/arch/arm/mach-mmp/include/mach/camera.h
new file mode 100644
index 000..b008f3f
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/camera.h
@@ -0,0 +1,33 @@
+/*
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.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.
+ *
+ */
+
+#ifndef __ASM_ARCH_CAMERA_H__
+#define __ASM_ARCH_CAMERA_H__
+
+#define MAX_CAM_CLK 3
+struct mv_cam_pdata {
+ struct clk *clk[MAX_CAM_CLK];
+ char *name;
+ int clk_enabled;
+ int dphy[3];
+ int bus_type;
+ int dma_burst;
+ int qos_req_min;
+ int mclk_min;
+ int mclk_src;
+ int (*clk_init) (struct device *dev, int init);
+ void (*set_clock) (struct device *dev, int on);
+ int (*get_mclk_src) (int src);
+};
+
+#endif
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 3be180b..3b7a70e 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -891,6 +891,13 @@ config VIDEO_MX3
---help---
This is a v4l2 driver for the i.MX3x Camera Sensor Interface
+config VIDEO_MV
+ tristate Marvell CMOS Camera Interface Controller driver
+ depends on VIDEO_DEV CPU_PXA910 SOC_CAMERA
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This is a v4l2 driver for the Marvell CCIC Interface
+
config VIDEO_PXA27x
tristate PXA27x Quick Capture Interface driver
depends on VIDEO_DEV PXA27x SOC_CAMERA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 9519160..373b706 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o
obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
+obj-$(CONFIG_VIDEO_MV) += mv_camera.o
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o
diff --git a/drivers/media/video/mv_camera.c b/drivers/media/video/mv_camera.c
new file mode 100644
index 000..1a8f73e
--- /dev/null
+++ b/drivers/media/video/mv_camera.c
@@ -0,0 +1,1120 @@
+/*
+ * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
+ * (CMOS Capture Interface Controller)
+ *
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.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.
+ *
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/io.h
+#include linux/delay.h
+#include linux/dma-mapping.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/time.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/slab.h
+#include linux/videodev2.h
+
+#include media/v4l2-common.h
+#include media/v4l2-dev.h
+#include media/videobuf2-dma-contig.h
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+
+#include mach/camera.h
+#include cafe_ccic-regs.h
+
+/* Register definition for PXA910 */
+
+#define REG_U0BAR 0x0c
+#define REG_U1BAR 0x10
+#define REG_U2BAR 0x14
+#define REG_V0BAR 0x18
+#define REG_V1BAR 0x1C
+#define REG_V2BAR 0x20
+
+/* for MIPI enable */
+#define REG_CSI2_CTRL0 0x100
+#define REG_CSI2_DPHY0 0x120
+#define REG_CSI2_DPHY1 0x124
+#define REG_CSI2_DPHY2 0x128
+#define REG_CSI2_DPHY3 0x12c
+#define REG_CSI2_DPHY4 0x130
+#define REG_CSI2_DPHY5 0x134
+#define REG_CSI2_DPHY6 0x138
Re: pxa ccic driver based on soc_camera and videobuf
hi, Guennadi: thanks for your comments. I converted it to videobuf2 and send it out in another thread. [PATCH] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC would you please review ? thanks 2011/5/18 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi Kassey On Wed, 18 May 2011, Kassey Lee wrote: hi, Guennadi, Hans: I just converted Marvell CCIC driver from ccic_cafe to soc_camera + videobuf, and make it stable and robust. Nice! do you accept the soc_camera + videobuf to the latest kernel ? My understanding is, that since videobuf2 is really an improved videobuf, the latter shall be deprecated and removed in some time, after all existing drivers are converted, so, there is no point in developing new drivers with videobuf. That said, the conversion is not very difficult, so, please, either do it yourself (preferred;)), or post your driver as is and we'll help you convert it. 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
pxa ccic driver based on soc_camera and videobuf
hi, Guennadi, Hans: I just converted Marvell CCIC driver from ccic_cafe to soc_camera + videobuf, and make it stable and robust. do you accept the soc_camera + videobuf to the latest kernel ? thanks Best regards Kassey Email: y...@marvell.com Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- 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
MIPI flag support updated
Hi, Guennadi , Hans: I've updated the patch to support MIPI flag for camera sensor and host controller as you suggested, would you please have time to review ? http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/27609/focus=28195 thanks -- 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 2.6.39] soc_camera: OMAP1: fix missing bytesperline and sizeimage initialization
2011/4/12 Kassey Lee kassey1...@gmail.com: Hi, Guennadi; for sizeimage , I agree with you. that we can overwrite it after a frame is done. for byteperline: on Marvell soc. it needs to know the bytesperline before receive frame from sensor. what we did now is hardcode in host driver for bytesperline. since different sensors have different timing for JPEG, and bytesperline is different. while soc_mbus_bytes_per_line does not support JPEG. So, we want that host driver can get byteperline from sensor driver (sub dev) before transfer a frame for JPEG format. a way to do this: soc_mbus_bytes_per_line return 0 for JPEG, and host driver will try another API to get bytesperline for JPEG from sensor driver. the effort is new API or reused other API. Is that reasonable ? 2011/4/12 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi On Tue, 12 Apr 2011, Kassey Lee wrote: hi, Guennadi: a lot of sensors support JPEG output. 1) bytesperline is defined by sensor timing. 2) and sizeimage is unknow for jpeg. how about for JPEG 1) host driver gets bytesperline from sensor driver. 2) sizeimage refilled by host driver after dma transfer done( a frame is received) thanks. How is this done currently on other V4L2 drivers? To transfer a frame you usually first do at least one of S_FMT and G_FMT, at which time you already have to report sizeimage to the user - before any transfer has taken place. Currently with soc-camera it is already possible to override sizeimage and bytesperline from the host driver. Just set them to whatever you need in your try_fmt and they will be kept. Not sure how you want to do that, if you need to first read in a frame - do you want to perform some dummy frame transfer? You might not even have any buffers queued yet, so, it has to be a read without writing to RAM. Don't such compressed formats just put a value in sizeimage, that is a calculated maximum size? Thanks Guennadi 2011/4/11 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi Janusz On Sat, 9 Apr 2011, Janusz Krzysztofik wrote: Since commit 0e4c180d3e2cc11e248f29d4c604b6194739d05a, bytesperline and sizeimage memebers of v4l2_pix_format structure have no longer been calculated inside soc_camera_g_fmt_vid_cap(), but rather passed via soc_camera_device structure from a host driver callback invoked by soc_camera_set_fmt(). OMAP1 camera host driver has never been providing these parameters, so it no longer works correctly. Fix it by adding suitable assignments to omap1_cam_set_fmt(). Thanks for the patch, but now it looks like many soc-camera host drivers are re-implementing this very same calculation in different parts of their code - in try_fmt, set_fmt, get_fmt. Why don't we unify them all, implement this centrally in soc_camera.c and remove all those calculations? Could you cook up a patch or maybe several patches - for soc_camera.c and all drivers? Thanks Guennadi Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- drivers/media/video/omap1_camera.c | 6 ++ 1 file changed, 6 insertions(+) --- linux-2.6.39-rc2/drivers/media/video/omap1_camera.c.orig 2011-04-06 14:30:37.0 +0200 +++ linux-2.6.39-rc2/drivers/media/video/omap1_camera.c 2011-04-09 00:16:36.0 +0200 @@ -1292,6 +1292,12 @@ static int omap1_cam_set_fmt(struct soc_ pix-colorspace = mf.colorspace; icd-current_fmt = xlate; + pix-bytesperline = soc_mbus_bytes_per_line(pix-width, + xlate-host_fmt); + if (pix-bytesperline 0) + return pix-bytesperline; + pix-sizeimage = pix-height * pix-bytesperline; + return 0; } --- 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 --- 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 -- 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 2.6.39] soc_camera: OMAP1: fix missing bytesperline and sizeimage initialization
Yes, thank you very much! 2011/4/12 Guennadi Liakhovetski g.liakhovet...@gmx.de: On Tue, 12 Apr 2011, Kassey Lee wrote: 2011/4/12 Kassey Lee kassey1...@gmail.com: Hi, Guennadi; for sizeimage , I agree with you. that we can overwrite it after a frame is done. for byteperline: on Marvell soc. it needs to know the bytesperline before receive frame from sensor. what we did now is hardcode in host driver for bytesperline. since different sensors have different timing for JPEG, and bytesperline is different. while soc_mbus_bytes_per_line does not support JPEG. So, we want that host driver can get byteperline from sensor driver (sub dev) before transfer a frame for JPEG format. a way to do this: soc_mbus_bytes_per_line return 0 for JPEG, and host driver will try another API to get bytesperline for JPEG from sensor driver. the effort is new API or reused other API. Is that reasonable ? If you mean this your patch http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/31323/match= then I've queued it for 2.6.40. Thanks Guennadi 2011/4/12 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi On Tue, 12 Apr 2011, Kassey Lee wrote: hi, Guennadi: a lot of sensors support JPEG output. 1) bytesperline is defined by sensor timing. 2) and sizeimage is unknow for jpeg. how about for JPEG 1) host driver gets bytesperline from sensor driver. 2) sizeimage refilled by host driver after dma transfer done( a frame is received) thanks. How is this done currently on other V4L2 drivers? To transfer a frame you usually first do at least one of S_FMT and G_FMT, at which time you already have to report sizeimage to the user - before any transfer has taken place. Currently with soc-camera it is already possible to override sizeimage and bytesperline from the host driver. Just set them to whatever you need in your try_fmt and they will be kept. Not sure how you want to do that, if you need to first read in a frame - do you want to perform some dummy frame transfer? You might not even have any buffers queued yet, so, it has to be a read without writing to RAM. Don't such compressed formats just put a value in sizeimage, that is a calculated maximum size? Thanks Guennadi 2011/4/11 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi Janusz On Sat, 9 Apr 2011, Janusz Krzysztofik wrote: Since commit 0e4c180d3e2cc11e248f29d4c604b6194739d05a, bytesperline and sizeimage memebers of v4l2_pix_format structure have no longer been calculated inside soc_camera_g_fmt_vid_cap(), but rather passed via soc_camera_device structure from a host driver callback invoked by soc_camera_set_fmt(). OMAP1 camera host driver has never been providing these parameters, so it no longer works correctly. Fix it by adding suitable assignments to omap1_cam_set_fmt(). Thanks for the patch, but now it looks like many soc-camera host drivers are re-implementing this very same calculation in different parts of their code - in try_fmt, set_fmt, get_fmt. Why don't we unify them all, implement this centrally in soc_camera.c and remove all those calculations? Could you cook up a patch or maybe several patches - for soc_camera.c and all drivers? Thanks Guennadi Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- drivers/media/video/omap1_camera.c | 6 ++ 1 file changed, 6 insertions(+) --- linux-2.6.39-rc2/drivers/media/video/omap1_camera.c.orig 2011-04-06 14:30:37.0 +0200 +++ linux-2.6.39-rc2/drivers/media/video/omap1_camera.c 2011-04-09 00:16:36.0 +0200 @@ -1292,6 +1292,12 @@ static int omap1_cam_set_fmt(struct soc_ pix-colorspace = mf.colorspace; icd-current_fmt = xlate; + pix-bytesperline = soc_mbus_bytes_per_line(pix-width, + xlate-host_fmt); + if (pix-bytesperline 0) + return pix-bytesperline; + pix-sizeimage = pix-height * pix-bytesperline; + return 0; } --- 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 --- 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 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open
Re: [PATCH 2.6.39] soc_camera: OMAP1: fix missing bytesperline and sizeimage initialization
hi, Guennadi: a lot of sensors support JPEG output. 1) bytesperline is defined by sensor timing. 2) and sizeimage is unknow for jpeg. how about for JPEG 1) host driver gets bytesperline from sensor driver. 2) sizeimage refilled by host driver after dma transfer done( a frame is received) thanks. 2011/4/11 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi Janusz On Sat, 9 Apr 2011, Janusz Krzysztofik wrote: Since commit 0e4c180d3e2cc11e248f29d4c604b6194739d05a, bytesperline and sizeimage memebers of v4l2_pix_format structure have no longer been calculated inside soc_camera_g_fmt_vid_cap(), but rather passed via soc_camera_device structure from a host driver callback invoked by soc_camera_set_fmt(). OMAP1 camera host driver has never been providing these parameters, so it no longer works correctly. Fix it by adding suitable assignments to omap1_cam_set_fmt(). Thanks for the patch, but now it looks like many soc-camera host drivers are re-implementing this very same calculation in different parts of their code - in try_fmt, set_fmt, get_fmt. Why don't we unify them all, implement this centrally in soc_camera.c and remove all those calculations? Could you cook up a patch or maybe several patches - for soc_camera.c and all drivers? Thanks Guennadi Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- drivers/media/video/omap1_camera.c | 6 ++ 1 file changed, 6 insertions(+) --- linux-2.6.39-rc2/drivers/media/video/omap1_camera.c.orig 2011-04-06 14:30:37.0 +0200 +++ linux-2.6.39-rc2/drivers/media/video/omap1_camera.c 2011-04-09 00:16:36.0 +0200 @@ -1292,6 +1292,12 @@ static int omap1_cam_set_fmt(struct soc_ pix-colorspace = mf.colorspace; icd-current_fmt = xlate; + pix-bytesperline = soc_mbus_bytes_per_line(pix-width, + xlate-host_fmt); + if (pix-bytesperline 0) + return pix-bytesperline; + pix-sizeimage = pix-height * pix-bytesperline; + return 0; } --- 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 -- 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
