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
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
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
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
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
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
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
---
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
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
...@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
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
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
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
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
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
.
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
, 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
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
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
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.
...@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
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
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
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
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
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
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
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
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
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
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
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
32 matches
Mail list logo
