Re: [PATCH v2 2/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers - part 1
Hi Xiaolin, On Sunday 28 March 2010 16:42:30 Zhang, Xiaolin wrote: > From 1c18c41be33246e4b766d0e95e28a72dded87475 Mon Sep 17 00:00:00 2001 > From: Xiaolin Zhang > Date: Sun, 28 Mar 2010 21:31:24 +0800 > Subject: [PATCH 2/10] This patch is second part of intel moorestown isp > driver and c files collection which is v4l2 implementation. > > +struct videobuf_dma_contig_memory { > + u32 magic; > + void *vaddr; > + dma_addr_t dma_handle; > + unsigned long size; > + int is_userptr; > +}; > + > +#define MAGIC_DC_MEM 0x0733ac61 > +#define MAGIC_CHECK(is, should) > \ > + if (unlikely((is) != (should))) { \ > + pr_err("magic mismatch: %x expected %x\n", (is), (should)); \ > + BUG(); \ > + } I will do a more in-depth review in a few days. However, I did notice that you added your own dma_contig implementation. What were the reasons for doing this? I've CC-ed Pawel since he will be interested in this as well. Another question that came up is: what is 'marvin'? It's clearly a codename, but a codename for what? This should be documented at the top of some source or header. Apologies if it is already documented, I didn't read everything yet. A final point I noticed: don't cast away a function result: (void)ci_isp_set_bp_detection(NULL); No need for (void). The gcc compiler won't warn about this unless the function is annotated with __must_check__. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: What would be a good time to move subdev drivers to a subdev directory?
On Monday 29 March 2010 01:08:23 Andy Walls wrote: > On Sun, 2010-03-28 at 18:03 +0200, Hans Verkuil wrote: > > On Sunday 28 March 2010 17:38:31 Mauro Carvalho Chehab wrote: > > > Hans Verkuil wrote: > > > > So, let's get some feedback from developers about this again. Whatever > > > decided, > > > we should clearly document the used criteria, to avoid having drivers > > > misplaced. > > > > 1) Reusable subdev drivers go into the subdev directory. > > OK by me. > > I will note the cx25840 module is used stand-alone and by the cx23885 > and cx231xx drivers as an integrated A/V core. However the integrated > core is internally I2C connected so it's fairly loosely coupled. I > don't see a problem with the cx25840 module being pushed into a subdev > directory. > > > > 2) Subdev drivers that are tightly coupled to a bridge or platform driver go > > into the subdirectory containing that bridge or platform driver. > > Ack. > > > > Rule 1 applies to roughly 50 subdev drivers. > > > > I wonder if for rule 2 we should require that subdev drivers would go into a > > /subdev directory. It would help in keeping track of what is > > what, > > but this may be overkill. > > NAK. That is overkill. > > > > BTW, here are some exceptional cases to ponder: > > Where does the cx2341x module go? It is common code used by ivtv, cx18, > and cx23885 (and probably cx88), but it is not a subdevice. > > Also some code in cx23885/cx23888-ir.c could be broken out and shared > between the cx25840, cx18, and cx231xx modules since it is the same IR > hardware (mostly), but connected to the bridge chip differently. Where > would that go? It is common code for Conexant bridge drivers. So it definitely belongs under media/video. Perhaps we might want to move it to media/video/cx-common, but personally I do not think that is needed. Regards, Hans > > Regards, > Andy > > -- > 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 > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
MPEG2 encoder uPD61151 next...
Hi All. I have more questions now. Our card has DVB-T zl10353. Befor start encoder need set its out to Z-state. How to I can do it? This is my last big problem. Startup step by step: Call zarlink to set Z-state of a bus. Configure TS port of the saa7134 to PARALLEL_PS and config other regs Configure DMA of a TS Prepare settings for uPD61151 encoder Enable MPEG out of the uPD61151 by GPIO pin of the saa7134 Start DMA and TS Start encoder Stop step by step: Stop encoder Stop DMA and TS Disable MPEG out by GPIO pin of the saa7134 Zarlink and encoder connected to same bus and has different TS config. I need know who want use TS: zarlink or encoder. Now to I can do it? > Um, what is the 'Z state' of a bus? Write special value to command register of the zl10353. The chip disconnect internal bus from output bus. This bus used for send MPEG TS data from zl10353 to saa7134. uPD61151 and zl10353 connected to the same bus. At one time only one chip can send MPEG TS data to the saa7134. When DVB-T mode zl10353 send date, uPD61151 disconnected from a bus. When MPEG2 encode mode, uPD61151 send date, zl10353 disconnected from a bus. With my best regards, Dmitry. -- 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] What are the goals for the architecture of an in-kernel IR system?
Mauro Carvalho Chehab wrote: > Dmitry Torokhov wrote: >> On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote: >>> David Härdeman wrote: On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote: >>10) extend keycode table replacement to support big/variable >>sized scancodes; > Pending. > > The current limit here is the scancode ioctl's are defined as: > > #define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) > /* get keycode */ > #define EVIOCSKEYCODE _IOW('E', 0x04, int[2]) > /* set keycode */ > > As int size is 32 bits, and we must pass both 64 (or even bigger) > scancodes, associated > with a keycode, there's not enough bits there for IR. > > The better approach seems to create an struct with an arbitrary long > size, like: > > struct keycode_table_entry { > unsigned keycode; > char scancode[32]; /* 32 is just an arbitrary long array - maybe > shorter */ > int len; > } > > and re-define the ioctls. For example we might be doing: > > #define EVIOCGKEYCODEBIG _IOR('E', 0x04, struct > keycode_table_entry) > #define EVIOCSKEYCODEBIG _IOW('E', 0x04, struct > keycode_table_entry) > #define EVIOCLEARKEYCODEBIG_IOR('E', 0x04, void) > > Provided that the size for struct keycode_table_entry is different, _IO > will generate > a different magic number for those. > > Or, instead of using 0x04, just use another sequential number at the 'E' > namespace. > > An specific function to clear the table is needed with big scancode space, > as already discussed. > I'd suggest: struct keycode_table_entry { unsigned keycode; unsigned index; unsigned len; char scancode[]; }; Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are ignored), that way no special function to clear the table is necessary, instead you do a loop with: EVIOCGKEYCODEBIG (with index 0) EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and keycode = KEY_RESERVED) until EVIOCGKEYCODEBIG returns an error. >>> Makes sense. >> Yes, I think so too. Just need a nice way to handle transition, I'd >> like in the end to have drivers implement only the improved methods and >> map legacy methods in evdev. > > See the attached RFC barely tested patch. > > On this patch, I'm using the following definitions for the ioctl: > > struct keycode_table_entry { > __u32 keycode; /* e.g. KEY_A */ > __u32 index;/* Index for the given scan/key table */ > __u32 len; /* Lenght of the scancode */ > __u32 reserved[2]; /* Reserved for future usage */ > char *scancode; /* scancode, in machine-endian */ > }; > > #define EVIOCGKEYCODEBIG _IOR('E', 0x04, struct keycode_table_entry) /* > get keycode */ > #define EVIOCSKEYCODEBIG _IOW('E', 0x04, struct keycode_table_entry) /* > set keycode */ > > > I tried to do the compat backport on a nice way, on both directions, e. g.: > > 1) an userspace app using EVIO[CS]GKEYCODEBIG to work with a legacy driver. > 2) a driver implementing the new methods to accept the legacy > EVIO[CS]GKEYCODE; > > For the test of (1), I implemented the following clear keytable code: > > struct keycode_table_entry kt; > uint32_tscancode, i; > > memset(&kt, 0, sizeof(kt)); > kt.len = sizeof(scancode); > kt.scancode = (char *)&scancode; > > for (i = 0; rc == 0; i++) { > kt.index = i; > kt.keycode = KEY_RESERVED; > rc = ioctl(fd, EVIOCSKEYCODEBIG, &kt); > } > fprintf(stderr, "Cleaned %i keycode(s)\n", i - 1); > > It worked properly. I didn't test (2) yet. > > The read keytable would also be trivial. However, there are some troubles when > implementing the code to add/replace a value at the table, in a way that it > would allow the legacy drivers to work: > > - With a real CODEBIG support, the index number will be different than the > scancode number. So, let's say that this is the driver table: > > index scancode keycode > > 0 0x1e00 KEY_0 > 1 0x1e01 KEY_1 > 2 0x1e02 KEY_2 > 3 0x1e03 KEY_3 > 4 0x1e04 KEY_4 > 5 0x1e05 KEY_5 > 6 0x1e06 KEY_6 > 7 0x1e07 KEY_7 > 8 0x1e08 KEY_8 > 9 0x1e09 KEY_9 > > Let's suppose that the user wants to overwrite the entry 5, attributing a new > scancode/keycode > to entry 5 (for example, associating 0x1e0a with KEY-A). > > A valid EVIOCSKEYCODEBIG call to change this code would be: > > kt->index = 5; > *(uint32_t *)kt->scancode = 0x1e0a; > *(uin
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Dmitry Torokhov wrote: > On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote: >> David Härdeman wrote: >>> On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote: >10) extend keycode table replacement to support big/variable >sized scancodes; Pending. The current limit here is the scancode ioctl's are defined as: #define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /* get keycode */ #define EVIOCSKEYCODE _IOW('E', 0x04, int[2]) /* set keycode */ As int size is 32 bits, and we must pass both 64 (or even bigger) scancodes, associated with a keycode, there's not enough bits there for IR. The better approach seems to create an struct with an arbitrary long size, like: struct keycode_table_entry { unsigned keycode; char scancode[32]; /* 32 is just an arbitrary long array - maybe shorter */ int len; } and re-define the ioctls. For example we might be doing: #define EVIOCGKEYCODEBIG _IOR('E', 0x04, struct keycode_table_entry) #define EVIOCSKEYCODEBIG _IOW('E', 0x04, struct keycode_table_entry) #define EVIOCLEARKEYCODEBIG_IOR('E', 0x04, void) Provided that the size for struct keycode_table_entry is different, _IO will generate a different magic number for those. Or, instead of using 0x04, just use another sequential number at the 'E' namespace. An specific function to clear the table is needed with big scancode space, as already discussed. >>> I'd suggest: >>> >>> struct keycode_table_entry { >>> unsigned keycode; >>> unsigned index; >>> unsigned len; >>> char scancode[]; >>> }; >>> >>> Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are >>> ignored), that way no special function to clear the table is necessary, >>> instead you do a loop with: >>> >>> EVIOCGKEYCODEBIG (with index 0) >>> EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and >>> keycode = KEY_RESERVED) >>> >>> until EVIOCGKEYCODEBIG returns an error. >> Makes sense. > > Yes, I think so too. Just need a nice way to handle transition, I'd > like in the end to have drivers implement only the improved methods and > map legacy methods in evdev. See the attached RFC barely tested patch. On this patch, I'm using the following definitions for the ioctl: struct keycode_table_entry { __u32 keycode; /* e.g. KEY_A */ __u32 index;/* Index for the given scan/key table */ __u32 len; /* Lenght of the scancode */ __u32 reserved[2]; /* Reserved for future usage */ char *scancode; /* scancode, in machine-endian */ }; #define EVIOCGKEYCODEBIG_IOR('E', 0x04, struct keycode_table_entry) /* get keycode */ #define EVIOCSKEYCODEBIG_IOW('E', 0x04, struct keycode_table_entry) /* set keycode */ I tried to do the compat backport on a nice way, on both directions, e. g.: 1) an userspace app using EVIO[CS]GKEYCODEBIG to work with a legacy driver. 2) a driver implementing the new methods to accept the legacy EVIO[CS]GKEYCODE; For the test of (1), I implemented the following clear keytable code: struct keycode_table_entry kt; uint32_tscancode, i; memset(&kt, 0, sizeof(kt)); kt.len = sizeof(scancode); kt.scancode = (char *)&scancode; for (i = 0; rc == 0; i++) { kt.index = i; kt.keycode = KEY_RESERVED; rc = ioctl(fd, EVIOCSKEYCODEBIG, &kt); } fprintf(stderr, "Cleaned %i keycode(s)\n", i - 1); It worked properly. I didn't test (2) yet. The read keytable would also be trivial. However, there are some troubles when implementing the code to add/replace a value at the table, in a way that it would allow the legacy drivers to work: - With a real CODEBIG support, the index number will be different than the scancode number. So, let's say that this is the driver table: index scancode keycode 0 0x1e00 KEY_0 1 0x1e01 KEY_1 2 0x1e02 KEY_2 3 0x1e03 KEY_3 4 0x1e04 KEY_4 5 0x1e05 KEY_5 6 0x1e06 KEY_6 7 0x1e07 KEY_7 8 0x1e08 KEY_8 9 0x1e09 KEY_9 Let's suppose that the user wants to overwrite the entry 5, attributing a new scancode/keycode to entry 5 (for example, associating 0x1e0a with KEY-A). A valid EVIOCSKEYCODEBIG call to change this code would be: kt->index = 5; *(uint32_t *)kt->scancode = 0x1e0a; *(uint32_t *)kt->keycode = KEY_A; rc = ioctl(fd, EVIOCSKEYCODEBIG, &kt); With EVIOCSKEYCODE, this requires two separate operations: int codes[2]; code[0] = 0x1e05;
Re: What would be a good time to move subdev drivers to a subdev directory?
On Sun, 2010-03-28 at 18:03 +0200, Hans Verkuil wrote: > On Sunday 28 March 2010 17:38:31 Mauro Carvalho Chehab wrote: > > Hans Verkuil wrote: > > So, let's get some feedback from developers about this again. Whatever > > decided, > > we should clearly document the used criteria, to avoid having drivers > > misplaced. > > 1) Reusable subdev drivers go into the subdev directory. OK by me. I will note the cx25840 module is used stand-alone and by the cx23885 and cx231xx drivers as an integrated A/V core. However the integrated core is internally I2C connected so it's fairly loosely coupled. I don't see a problem with the cx25840 module being pushed into a subdev directory. > 2) Subdev drivers that are tightly coupled to a bridge or platform driver go > into the subdirectory containing that bridge or platform driver. Ack. > Rule 1 applies to roughly 50 subdev drivers. > > I wonder if for rule 2 we should require that subdev drivers would go into a > /subdev directory. It would help in keeping track of what is > what, > but this may be overkill. NAK. That is overkill. BTW, here are some exceptional cases to ponder: Where does the cx2341x module go? It is common code used by ivtv, cx18, and cx23885 (and probably cx88), but it is not a subdevice. Also some code in cx23885/cx23888-ir.c could be broken out and shared between the cx25840, cx18, and cx231xx modules since it is the same IR hardware (mostly), but connected to the bridge chip differently. Where would that go? Regards, Andy -- 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] drivers/media/IR - improve keytable code
The attached patch rewrites much of the keytable code in drivers/media/IR/ir-keytable.c. (applies to http://git.linuxtv.org/mchehab/ir.git) The scancodes are now inserted into the array in sorted order which allows for a binary search on lookup. The code has also been shrunk by about 150 lines. In addition it fixes the following bugs: Any use of ir_seek_table() was racy. ir_dev->driver_name is leaked between ir_input_register() and ir_input_unregister(). ir_setkeycode() unconditionally does clear_bit() on dev->keybit when removing a mapping, but there might be another mapping with a different scancode and the same keycode. Signed-off-by: David Härdeman --- drivers/media/IR/ir-keymaps.c |2 + drivers/media/IR/ir-keytable.c | 516 ++- include/media/ir-core.h|4 +- 3 files changed, 190 insertions(+), 332 deletions(-) diff --git a/drivers/media/IR/ir-keymaps.c b/drivers/media/IR/ir-keymaps.c index 55e7acd..bae8522 100644 --- a/drivers/media/IR/ir-keymaps.c +++ b/drivers/media/IR/ir-keymaps.c @@ -39,6 +39,8 @@ struct ir_scancode_table tabname ## _table = { \ .scan = tabname,\ .size = ARRAY_SIZE(tabname),\ + .len = ARRAY_SIZE(tabname), \ + .alloc = 0, \ .ir_type = type,\ .name = #irname,\ }; \ diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c index ad41af0..cd51bab 100644 --- a/drivers/media/IR/ir-keytable.c +++ b/drivers/media/IR/ir-keytable.c @@ -16,344 +16,216 @@ #include #include -#define IR_TAB_MIN_SIZE32 -#define IR_TAB_MAX_SIZE1024 +#define IR_TAB_MIN_SIZE1024 +#define IR_TAB_MAX_SIZE8192 /** - * ir_seek_table() - returns the element order on the table - * @rc_tab:the ir_scancode_table with the keymap to be used - * @scancode: the scancode that we're seeking + * ir_resize_table() - resizes a scancode table if necessary + * @rc_tab:the ir_scancode_table to resize + * @return:zero on success or a negative error code * - * This routine is used by the input routines when a key is pressed at the - * IR. The scancode is received and needs to be converted into a keycode. - * If the key is not found, it returns KEY_UNKNOWN. Otherwise, returns the - * corresponding keycode from the table. + * This routine will shrink the ir_scancode_table if it has lots of + * unused entries and grow it if it is full. */ -static int ir_seek_table(struct ir_scancode_table *rc_tab, u32 scancode) +static int ir_resize_table(struct ir_scancode_table *rc_tab) { - int rc; - unsigned long flags; - struct ir_scancode *keymap = rc_tab->scan; + unsigned int oldalloc = rc_tab->alloc; + unsigned int newalloc = oldalloc; + struct ir_scancode *oldscan = rc_tab->scan; + struct ir_scancode *newscan; + + if (rc_tab->size == rc_tab->len) { + /* All entries in use -> grow keytable */ + if (rc_tab->alloc >= IR_TAB_MAX_SIZE) + return -ENOMEM; - spin_lock_irqsave(&rc_tab->lock, flags); + if (oldalloc == 0) + newalloc = IR_TAB_MIN_SIZE; + else + newalloc *= 2; + IR_dprintk(1, "Growing table to %u bytes\n", newalloc); + } - /* FIXME: replace it by a binary search */ + if ((rc_tab->len * 3 < rc_tab->size) && (oldalloc > IR_TAB_MIN_SIZE)) { + /* Less than 1/3 of entries in use -> shrink keytable */ + newalloc /= 2; + IR_dprintk(1, "Shrinking table to %u bytes\n", newalloc); + } - for (rc = 0; rc < rc_tab->size; rc++) - if (keymap[rc].scancode == scancode) - goto exit; + if (newalloc == oldalloc) + return 0; - /* Not found */ - rc = -EINVAL; + newscan = kmalloc(newalloc, GFP_ATOMIC); + if (!newscan) { + IR_dprintk(1, "Failed to kmalloc %u bytes\n", newalloc); + return -ENOMEM; + } -exit: - spin_unlock_irqrestore(&rc_tab->lock, flags); - return rc; + memcpy(newscan, rc_tab->scan, rc_tab->len * sizeof(struct ir_scancode)); + rc_tab->scan = newscan; + rc_tab->alloc = newalloc; + rc_tab->size = rc_tab->alloc / sizeof(struct ir_scancode); + kfree(oldscan); + return 0; } /** - * ir_roundup_tablesize() - gets an optimum value for the table size - * @n_elems: minimum number of entries to store keycodes - * - * This routine is used to choose the keycode table size. + * ir_do_setkeycode() - internal function to set a keycode in the + *
Re: [PATCH] V4L/DVB: mx1-camera: compile fix
On Sat, 27 Mar 2010, Uwe Kleine-König wrote: > This fixes a regression of > > 7d58289 (mx1: prefix SOC specific defines with MX1_ and deprecate old > names) > > Signed-off-by: Uwe Kleine-König Sascha, I need your ack to pull this via my tree. Thanks Guennadi > --- > arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h |8 +++- > drivers/media/video/mx1_camera.c |8 +++- > 2 files changed, 10 insertions(+), 6 deletions(-) > > Hello, > > changed since last post: > > - put offset in the definition of MX1_DMA_REG in parenthesis > - describe register definitions now moved to dma-mx1-mx2.h with the full >register names and order by address. > > Thanks > Uwe > > diff --git a/arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h > b/arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h > index 07be8ad..4b63b05 100644 > --- a/arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h > +++ b/arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h > @@ -31,7 +31,13 @@ > #define DMA_MODE_WRITE 1 > #define DMA_MODE_MASK1 > > -#define DMA_BASE IO_ADDRESS(DMA_BASE_ADDR) > +#define MX1_DMA_REG(offset) MX1_IO_ADDRESS(MX1_DMA_BASE_ADDR + (offset)) > + > +/* DMA Interrupt Mask Register */ > +#define MX1_DMA_DIMR MX1_DMA_REG(0x08) > + > +/* Channel Control Register */ > +#define MX1_DMA_CCR(x) MX1_DMA_REG(0x8c + ((x) << 6)) > > #define IMX_DMA_MEMSIZE_32 (0 << 4) > #define IMX_DMA_MEMSIZE_8(1 << 4) > diff --git a/drivers/media/video/mx1_camera.c > b/drivers/media/video/mx1_camera.c > index c167cc3..aa81acd 100644 > --- a/drivers/media/video/mx1_camera.c > +++ b/drivers/media/video/mx1_camera.c > @@ -48,8 +48,6 @@ > /* > * CSI registers > */ > -#define DMA_CCR(x) (0x8c + ((x) << 6)) /* Control Registers */ > -#define DMA_DIMR 0x08/* Interrupt mask Register */ > #define CSICR1 0x00/* CSI Control Register > 1 */ > #define CSISR0x08/* CSI Status Register > */ > #define CSIRXR 0x10/* CSI RxFIFO Register > */ > @@ -783,7 +781,7 @@ static int __init mx1_camera_probe(struct platform_device > *pdev) > pcdev); > > imx_dma_config_channel(pcdev->dma_chan, IMX_DMA_TYPE_FIFO, > -IMX_DMA_MEMSIZE_32, DMA_REQ_CSI_R, 0); > +IMX_DMA_MEMSIZE_32, MX1_DMA_REQ_CSI_R, 0); > /* burst length : 16 words = 64 bytes */ > imx_dma_config_burstlen(pcdev->dma_chan, 0); > > @@ -797,8 +795,8 @@ static int __init mx1_camera_probe(struct platform_device > *pdev) > set_fiq_handler(&mx1_camera_sof_fiq_start, &mx1_camera_sof_fiq_end - > &mx1_camera_sof_fiq_start); > > - regs.ARM_r8 = DMA_BASE + DMA_DIMR; > - regs.ARM_r9 = DMA_BASE + DMA_CCR(pcdev->dma_chan); > + regs.ARM_r8 = (long)MX1_DMA_DIMR; > + regs.ARM_r9 = (long)MX1_DMA_CCR(pcdev->dma_chan); > regs.ARM_r10 = (long)pcdev->base + CSICR1; > regs.ARM_fp = (long)pcdev->base + CSISR; > regs.ARM_sp = 1 << pcdev->dma_chan; > -- > 1.7.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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Mar 28 19:00:15 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14536:a539e5b68945 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 8c69c6ed6c74c94fa7ad6fa24eda452e4b212d81 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-rc1-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-rc1-armv5-ixp: WARNINGS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-rc1-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-rc1-x86_64: WARNINGS linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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: Hauppauge WinTV HVR-900H
Am 28.03.2010 19:57, schrieb George Tellalov: >> I said debug, but I see no debug info for tm6000 is it "modprobe tm6000 >> debug=1 debug_i2c=3". From what havew you debug activated? Have you a crash >> dump in the dmesg log? Can tvtime crash, and if tvtime crashed, then send it >> to tvtime project (ask Devin Heitmueller). >> >> > Sorry that was only with debug=1. Also I didn't make myself clear about the > crash - it's a kernel crash (oops) not tvtime crash. I'm attaching a new debug > run togther with the oops message. The oops message might have typos because I > had to type it myself (no serial console on this pc). > I'm also unable to do a dvbscan are you interested in the debug output of the > scan? > No, say works, if dvb work. Not more. -- Stefan Ringel -- 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: Hauppauge WinTV HVR-900H
Am 28.03.2010 17:37, schrieb George Tellalov: > On Sun, Mar 28, 2010 at 02:12:10PM +0200, Stefan Ringel wrote: > >> >> >> >> - Original Nachricht >> Von: George Tellalov >> An: Stefan Ringel >> Datum: 28.03.2010 14:07 >> Betreff: Re: Hauppauge WinTV HVR-900H >> >> >>> On Sun, Mar 28, 2010 at 01:51:17PM +0200, Stefan Ringel wrote: >>> In what for mode, analog or dvb-t? >>> The test? It was in analog mode using tvtime. >>> >>> >> And the dmsg log (with debug info), so we can see what wrong is. What for >> options have you set in the .config file? >> >> > Okay the same result with 2.6.33. I'm attaching my .config and dmesg's output. > I also have debug=9 output but I'm not sure if it's appropriate to attach it > here. Maybe I should gzip it? > I have also this bug (v4l2 in tm6000)! It can go any time to find and bugfix it. Please, test the dvb mode, what I think works and resend test result. Stefan Ringel -- Stefan Ringel -- 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: Re: Re: Hauppauge WinTV HVR-900H
> > I said debug, but I see no debug info for tm6000 is it "modprobe tm6000 > debug=1 debug_i2c=3". From what havew you debug activated? Have you a crash > dump in the dmesg log? Can tvtime crash, and if tvtime crashed, then send it > to tvtime project (ask Devin Heitmueller). > Sorry that was only with debug=1. Also I didn't make myself clear about the crash - it's a kernel crash (oops) not tvtime crash. I'm attaching a new debug run togther with the oops message. The oops message might have typos because I had to type it myself (no serial console on this pc). I'm also unable to do a dvbscan are you interested in the debug output of the scan? oops.txt.gz Description: Binary data
Aw: Re: Re: Hauppauge WinTV HVR-900H
- Original Nachricht Von: George Tellalov An: Stefan Ringel Datum: 28.03.2010 17:37 Betreff: Re: Re: Hauppauge WinTV HVR-900H > On Sun, Mar 28, 2010 at 02:12:10PM +0200, Stefan Ringel wrote: > > > > > > > > - Original Nachricht > > Von: George Tellalov > > An: Stefan Ringel > > Datum: 28.03.2010 14:07 > > Betreff: Re: Hauppauge WinTV HVR-900H > > > > > On Sun, Mar 28, 2010 at 01:51:17PM +0200, Stefan Ringel wrote: > > > > > > > > In what for mode, analog or dvb-t? > > > > > > > > > > The test? It was in analog mode using tvtime. > > > > > > > And the dmsg log (with debug info), so we can see what wrong is. What for > options have you set in the .config file? > > > > Okay the same result with 2.6.33. I'm attaching my .config and dmesg's > output. > I also have debug=9 output but I'm not sure if it's appropriate to attach > it > here. Maybe I should gzip it? > I said debug, but I see no debug info for tm6000 is it "modprobe tm6000 debug=1 debug_i2c=3". From what havew you debug activated? Have you a crash dump in the dmesg log? Can tvtime crash, and if tvtime crashed, then send it to tvtime project (ask Devin Heitmueller). Stefan Ringel -- 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: What would be a good time to move subdev drivers to a subdev directory?
On Sunday 28 March 2010 17:38:31 Mauro Carvalho Chehab wrote: > Hans Verkuil wrote: > > Hi Mauro, > > > > Currently drivers/media/video is a mix of subdev drivers and bridge/platform > > drivers. I think it would be good to create a drivers/media/subdev directory > > where subdev drivers can go. > > > > We discussed in the past whether we should have categories for audio > > subdevs, > > video subdevs, etc. but I think that will cause problems, especially with > > future multifunction devices. > > Due to the discussions we had on the last time, I'm not so sure that such move > would be good: There are some cases where the division of a subdev is more a > matter of a logical organization than a physical device division. for example, > cx231xx is just one chip, but, as it has internally the same functionalities > as > a cx2584x, the cx2584x is a subdev used by the driver. There are other similar > examples on other IC's and SoC. I should have mentioned why I think it is a good idea to split it: right now it is not clear in media/video what the bridge drivers are and what the subdev drivers are. Note that integrated subdev drivers that are tightly coupled to a bridge or platform driver should stay with that driver (in practice these will always be in a driver-specific subdirectory), but subdevs that can be used stand-alone should (I think) be moved to their own 'subdev' subdirectory. It also makes no sense to me to mix bridge drivers and subdev drivers in one directory. They are simply different types of driver. I don't care whether they are moved to media/subdev or media/video/subdev. The latter is probably easier. > I remember that Oliver argued on that time that the better would be to reduce > the > number of subdirs, instead of increasing. On that discussions, I got > convinced > that he was right, but maybe we have some new reasons to create a subdev dir. > > So, let's get some feedback from developers about this again. Whatever > decided, > we should clearly document the used criteria, to avoid having drivers > misplaced. 1) Reusable subdev drivers go into the subdev directory. 2) Subdev drivers that are tightly coupled to a bridge or platform driver go into the subdirectory containing that bridge or platform driver. Rule 1 applies to roughly 50 subdev drivers. I wonder if for rule 2 we should require that subdev drivers would go into a /subdev directory. It would help in keeping track of what is what, but this may be overkill. > Ah, as we're talking about drivers directory, I'm intending to move the Remote > Controller common code to another place, likely drivers/input/rc or > drivers/rc. > The idea is to use this subsystem for pure input devices as well. By keeping > it > at drivers/media, it will be missplaced. Makes sense. > > > What is your opinion on this, and what would be a good time to start moving > > drivers? > > If we're doing this change, I prefer to generate the patch by the end of a > merge window, after merging from everybody else and being sure that trivial > patches > also got merged. OK, makes sense. > Comments? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
[GIT PATCHES FOR 2.6.35] videobuf refactoring
The following changes since commit 975b06b6c01ba2da4d26a7ba6ea783d5f670aa7d: Jonathan Corbet (1): V4L/DVB: ov7670: silence some compiler warnings are available in the git repository at: git://linuxtv.org/hverkuil/v4l-dvb-videobuf.git videobuf Hans Verkuil (8): v4l videobuf: remove unused mmap callback. v4l videobuf: remove mmap_free callback v4l videobuf: remove unused is_mmapped field v4l videobuf: use struct videobuf_buffer * instead of void * for videobuf_alloc v4l videobuf: rename .vmalloc to .vaddr v4l videobuf: rename videobuf_queue_to_vmalloc to videobuf_queue_to_vaddr v4l videobuf: add videobuf_buffer *buf as argument to mmap_mapper v4l videobuf: move video_copy_to_user and copy_stream to core. drivers/media/video/videobuf-core.c | 95 +++- drivers/media/video/videobuf-dma-contig.c | 109 +++ drivers/media/video/videobuf-dma-sg.c | 139 - drivers/media/video/videobuf-dvb.c|2 +- drivers/media/video/videobuf-vmalloc.c| 104 ++ include/media/videobuf-core.h | 29 ++- 6 files changed, 137 insertions(+), 341 deletions(-) Tested with cx88-blackbird, bttv, saa7134-empress, dvb-ttpci, vivi. The tests were done with userptr, mmap and read(). There is a lot more that needs to be done, but this is a good start. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: What would be a good time to move subdev drivers to a subdev directory?
Hans Verkuil wrote: > Hi Mauro, > > Currently drivers/media/video is a mix of subdev drivers and bridge/platform > drivers. I think it would be good to create a drivers/media/subdev directory > where subdev drivers can go. > > We discussed in the past whether we should have categories for audio subdevs, > video subdevs, etc. but I think that will cause problems, especially with > future multifunction devices. Due to the discussions we had on the last time, I'm not so sure that such move would be good: There are some cases where the division of a subdev is more a matter of a logical organization than a physical device division. for example, cx231xx is just one chip, but, as it has internally the same functionalities as a cx2584x, the cx2584x is a subdev used by the driver. There are other similar examples on other IC's and SoC. I remember that Oliver argued on that time that the better would be to reduce the number of subdirs, instead of increasing. On that discussions, I got convinced that he was right, but maybe we have some new reasons to create a subdev dir. So, let's get some feedback from developers about this again. Whatever decided, we should clearly document the used criteria, to avoid having drivers misplaced. Ah, as we're talking about drivers directory, I'm intending to move the Remote Controller common code to another place, likely drivers/input/rc or drivers/rc. The idea is to use this subsystem for pure input devices as well. By keeping it at drivers/media, it will be missplaced. > What is your opinion on this, and what would be a good time to start moving > drivers? If we're doing this change, I prefer to generate the patch by the end of a merge window, after merging from everybody else and being sure that trivial patches also got merged. Comments? -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] video/sn9c102: improve error handling
On Sun, Mar 28, 2010 at 05:09:48PM +0200, Christophe JAILLET wrote: > Hi, > > this patch seems incomplete. > > You had an opening { wityhout the corresponding }. It must be an issue with the mail server on your end. :/ Here is a url you can download it from. http://lkml.org/lkml/2010/3/28/43 Unfortunately, lkml.org puts some white space on the end of diffs. Patch complains but it still applies them fine. regards, dan carpenter -- 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 RFC v2] DVB: add dvb_generic_nonseekable_open, dvb_generic_unlocked_ioctl, use in firedtv
In order to remove Big Kernel Lock usages from the DVB subsystem, we need to - provide .llseek file operations that do not grab the BKL (unlike fs/read_write.c::default_llseek) or mark files as not seekable, - provide .unlocked_ioctl file operations. Add two dvb_generic_ file operations for file interfaces which are not seekable and, respectively, do not require the BKL in their ioctl handlers. Use them in one driver of which I am sure of that these are applicable. (Affected code paths in firedtv-ci were not runtime-tested since I don't have a CAM, but the frontend ioctls were of course runtime-tested.) Notes: - The dvb-core internal dvb_usercopy() API is changed to match .unlocked_ioctl() prototypes. - I suspect that all dvb_generic_open() users really want nonseekable_open --- then we should simply change dvb_generic_open() instead of adding dvb_generic_nonseekable_open() --- but I haven't checked other users of dvb_generic_open whether they require .llssek mehods other than fs/read_write.c::no_llseek. Applies to: drivers/media/dvb/ttpci/av7110.c drivers/media/dvb/ttpci/av7110_av.c drivers/media/dvb/ttpci/av7110_ca.c drivers/media/dvb/dvb-core/dvb_net.c drivers/media/dvb/dvb-core/dvb_frontend.c drivers/media/dvb/dvb-core/dvb_ca_en50221.c - To be done by those who know the code: Check all users of struct dvb_device.kernel_ioctl whether they really need the BKL. Convert to .unlocked_ioctl and remove .kernel_ioctl and the temporarily introduced dvbdev.c::legacy_usercopy(). Applies to: drivers/media/dvb/ttpci/av7110.c drivers/media/dvb/ttpci/av7110_av.c drivers/media/dvb/ttpci/av7110_ca.c drivers/media/dvb/dvb-core/dvb_frontend.c Signed-off-by: Stefan Richter --- Update: Split dvb_usercopy into one that follows the .unlocked_ioctl prototype form and another one that preserves the old form. drivers/media/dvb/dvb-core/dmxdev.c | 10 - drivers/media/dvb/dvb-core/dvb_ca_en50221.c |6 drivers/media/dvb/dvb-core/dvb_net.c|5 drivers/media/dvb/dvb-core/dvbdev.c | 190 +--- drivers/media/dvb/dvb-core/dvbdev.h | 23 +- drivers/media/dvb/firewire/firedtv-ci.c |9 6 files changed, 148 insertions(+), 95 deletions(-) Index: b/drivers/media/dvb/dvb-core/dmxdev.c === --- a/drivers/media/dvb/dvb-core/dmxdev.c +++ b/drivers/media/dvb/dvb-core/dmxdev.c @@ -963,8 +963,7 @@ dvb_demux_read(struct file *file, char _ return ret; } -static int dvb_demux_do_ioctl(struct inode *inode, struct file *file, - unsigned int cmd, void *parg) +static long dvb_demux_do_ioctl(struct file *file, unsigned int cmd, void *parg) { struct dmxdev_filter *dmxdevfilter = file->private_data; struct dmxdev *dmxdev = dmxdevfilter->dev; @@ -1087,7 +1086,7 @@ static int dvb_demux_do_ioctl(struct ino static int dvb_demux_ioctl(struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg) { - return dvb_usercopy(inode, file, cmd, arg, dvb_demux_do_ioctl); + return dvb_usercopy(file, cmd, arg, dvb_demux_do_ioctl); } static unsigned int dvb_demux_poll(struct file *file, poll_table *wait) @@ -1152,8 +1151,7 @@ static struct dvb_device dvbdev_demux = .fops = &dvb_demux_fops }; -static int dvb_dvr_do_ioctl(struct inode *inode, struct file *file, - unsigned int cmd, void *parg) +static long dvb_dvr_do_ioctl(struct file *file, unsigned int cmd, void *parg) { struct dvb_device *dvbdev = file->private_data; struct dmxdev *dmxdev = dvbdev->priv; @@ -1179,7 +1177,7 @@ static int dvb_dvr_do_ioctl(struct inode static int dvb_dvr_ioctl(struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg) { - return dvb_usercopy(inode, file, cmd, arg, dvb_dvr_do_ioctl); + return dvb_usercopy(file, cmd, arg, dvb_dvr_do_ioctl); } static unsigned int dvb_dvr_poll(struct file *file, poll_table *wait) Index: b/drivers/media/dvb/dvb-core/dvb_ca_en50221.c === --- a/drivers/media/dvb/dvb-core/dvb_ca_en50221.c +++ b/drivers/media/dvb/dvb-core/dvb_ca_en50221.c @@ -1181,8 +1181,8 @@ static int dvb_ca_en50221_thread(void *d * * @return 0 on success, <0 on error. */ -static int dvb_ca_en50221_io_do_ioctl(struct inode *inode, struct file *file, - unsigned int cmd, void *parg) +static long dvb_ca_en50221_io_do_ioctl(struct file *file, + unsigned int cmd, void *parg) { struct dvb_device *dvbdev = file->private_data; struct dvb_ca_private *ca = dvbdev->priv; @@ -1258,7 +1258,7 @@ static int dvb_ca_en50221_io_do_ioctl(st static int dvb_ca_en50221_io_ioctl(struct inode *inode, s
Re: Re: Hauppauge WinTV HVR-900H
On Sun, Mar 28, 2010 at 02:12:10PM +0200, Stefan Ringel wrote: > > > And the dmsg log (with debug info), so we can see what wrong is. What for > options have you set in the .config file? > Okay, I'm on my way to produce that log, but it will take a while. I'll have to recompile the driver and the kernel because the original compile I did was quite hacky. -- 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
Aw: Re: Hauppauge WinTV HVR-900H
- Original Nachricht Von: George Tellalov An: Stefan Ringel Datum: 28.03.2010 14:07 Betreff: Re: Hauppauge WinTV HVR-900H > On Sun, Mar 28, 2010 at 01:51:17PM +0200, Stefan Ringel wrote: > > > > In what for mode, analog or dvb-t? > > > > The test? It was in analog mode using tvtime. > And the dmsg log (with debug info), so we can see what wrong is. What for options have you set in the .config file? Stefan Ringel -- 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: Hauppauge WinTV HVR-900H
On Sun, Mar 28, 2010 at 01:51:17PM +0200, Stefan Ringel wrote: > > In what for mode, analog or dvb-t? > The test? It was in analog mode using tvtime. P.S. Sorry for the double reply, I forgot to reply to the list as well. -- 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
Aw: Hauppauge WinTV HVR-900H
- Original Nachricht Von: George Tellalov An: linux-media@vger.kernel.org Datum: 28.03.2010 12:51 Betreff: Hauppauge WinTV HVR-900H > Hello linux-media, > > I've recently bought an HVR-900H usb hybrid tuner (marketed as > 900-without-h) > and discovered that it's been unsupported for a while now. Nevertheless > some work is being done there: > http://www.mail-archive.com/linux-media@vger.kernel.org/msg16498.html > I've tried the patch (with linux 2.6.32) and I got as far as the firmware > being uploaded, but when I tried playing some TV it crashed the kernel. > I'm willing to help speeding up the driver development, so I was wondering > if > there's anything I can start with (like testing). Hopefully I'll be able to > do > some development later on, but I've got a lot of reading ahead before this > could > happen. > > Oh, yes - the device id is 2040:6600. > > Regards > George In what for mode, analog or dvb-t? Stefan Ringel -- 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] video/sn9c102: improve error handling
Return an error if the controller is not found. Signed-off-by: Dan Carpenter diff --git a/drivers/media/video/sn9c102/sn9c102_core.c b/drivers/media/video/sn9c102/sn9c102_core.c index cbf8087..28e19da 100644 --- a/drivers/media/video/sn9c102/sn9c102_core.c +++ b/drivers/media/video/sn9c102/sn9c102_core.c @@ -2295,7 +2295,7 @@ sn9c102_vidioc_s_ctrl(struct sn9c102_device* cam, void __user * arg) if (copy_from_user(&ctrl, arg, sizeof(ctrl))) return -EFAULT; - for (i = 0; i < ARRAY_SIZE(s->qctrl); i++) + for (i = 0; i < ARRAY_SIZE(s->qctrl); i++) { if (ctrl.id == s->qctrl[i].id) { if (s->qctrl[i].flags & V4L2_CTRL_FLAG_DISABLED) return -EINVAL; @@ -2305,7 +2305,9 @@ sn9c102_vidioc_s_ctrl(struct sn9c102_device* cam, void __user * arg) ctrl.value -= ctrl.value % s->qctrl[i].step; break; } - + } + if (i == ARRAY_SIZE(s->qctrl)) + return -EINVAL; if ((err = s->set_ctrl(cam, &ctrl))) return err; -- 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] video/et61x251: improve error handling
The original code doesn't handle the situation where the controller is not found. Signed-off-by: Dan Carpenter diff --git a/drivers/media/video/et61x251/et61x251_core.c b/drivers/media/video/et61x251/et61x251_core.c index e6c23d5..a5cfc76 100644 --- a/drivers/media/video/et61x251/et61x251_core.c +++ b/drivers/media/video/et61x251/et61x251_core.c @@ -1713,7 +1713,7 @@ et61x251_vidioc_s_ctrl(struct et61x251_device* cam, void __user * arg) if (copy_from_user(&ctrl, arg, sizeof(ctrl))) return -EFAULT; - for (i = 0; i < ARRAY_SIZE(s->qctrl); i++) + for (i = 0; i < ARRAY_SIZE(s->qctrl); i++) { if (ctrl.id == s->qctrl[i].id) { if (s->qctrl[i].flags & V4L2_CTRL_FLAG_DISABLED) return -EINVAL; @@ -1723,7 +1723,9 @@ et61x251_vidioc_s_ctrl(struct et61x251_device* cam, void __user * arg) ctrl.value -= ctrl.value % s->qctrl[i].step; break; } - + } + if (i == ARRAY_SIZE(s->qctrl)) + return -EINVAL; if ((err = s->set_ctrl(cam, &ctrl))) return err; -- 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] video/zc0301: improve error handling
Return an error if the controller is not found. Signed-off-by: Dan Carpenter diff --git a/drivers/media/video/zc0301/zc0301_core.c b/drivers/media/video/zc0301/zc0301_core.c index e44e4b5..bb51cfb 100644 --- a/drivers/media/video/zc0301/zc0301_core.c +++ b/drivers/media/video/zc0301/zc0301_core.c @@ -1153,7 +1153,7 @@ zc0301_vidioc_s_ctrl(struct zc0301_device* cam, void __user * arg) if (copy_from_user(&ctrl, arg, sizeof(ctrl))) return -EFAULT; - for (i = 0; i < ARRAY_SIZE(s->qctrl); i++) + for (i = 0; i < ARRAY_SIZE(s->qctrl); i++) { if (ctrl.id == s->qctrl[i].id) { if (s->qctrl[i].flags & V4L2_CTRL_FLAG_DISABLED) return -EINVAL; @@ -1163,7 +1163,9 @@ zc0301_vidioc_s_ctrl(struct zc0301_device* cam, void __user * arg) ctrl.value -= ctrl.value % s->qctrl[i].step; break; } - + } + if (i == ARRAY_SIZE(s->qctrl)) + return -EINVAL; if ((err = s->set_ctrl(cam, &ctrl))) return err; -- 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 0/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers
Hi Hans, Thank you comment. I will try to figure out why patch 2/10 is missing. maybe it is a little bit large. I will split it two more patches and resubmit again. BRs Xiaolin -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Sunday, March 28, 2010 4:31 PM To: Zhang, Xiaolin Cc: linux-media@vger.kernel.org; Zhu, Daniel; Yu, Jinlu; Wang, Wen W; Huang, Kai; Hu, Gang A; Ba, Zheng Subject: Re: [PATCH v2 0/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers Hi Xiaolin! Here are a few comments based on a first read-through. First of all, patch 2/10 did not seem to make it to the list for some reason. Because of that I'm deferring reviewing patches 1/10 and (of course) 2/10. The other patches for the i2c devices all have the same problems, so I will only review one and you can apply the comments made there to all the others. A general comment I have is that I think there is too much debugging code. Creating good debug code is an art. In my experience things like DBG_entering and DBG_leaving just clutter the code and are pretty useless once the initial implementation phase is finished. The trick is to have just enough debug or logging available so that you can deduce the path taken by the driver. What I found to be very useful as well is to implement VIDIOC_LOG_STATUS to get a full status overview of the various (sub)devices at a given moment. On Sunday 28 March 2010 09:46:35 Zhang, Xiaolin wrote: > Hi, > > Here is the second version of V4L2 camera sensors and ISP driver patch set to > support the Intel Moorestown camera imaging subsystem. > > The Camera Imaging interface (CI) in Moorestown is responsible for still > image and video capture which can handle demosaicing, color synthesis, > filtering, image enhancement, etc functionalities with a integrated JPEG > encode. > Intel Moorestown platform can support either a single camera or dual cameras. > If a platform with dual camera will have one low resolution camera on the > same side as this display for video conference and a high resolution camera > on the opposite side the display for high quality still image capture. > > The driver framework is updated to the v4l2 sub-dev and video buffer > framework, in this set of driver patches, I will submit the 10 patches to > enable the camera subsystem with the device drivers for ISP HW and 4 cameras > module (two SoCs: 1.3MP - Omnivision 9665, 2MP - Omnivison 2650 and two RAWs: > 5MP - Omnivision 5630, 5MP - Samsong s5k4e1). > > 1. Intel Moorestown ISP driver - header files. Just a single comment on these files here: I see new PIXFMT defines in a Moorestown-specific header: just add these to videodev2.h. Regards, Hans > 2. Intel Moorestown ISP driver - V4L2 implementation including hardware > component functionality > 3. Intel Moorestown flash sub-dev driver > 4. Intel Moorestown 2MP camera (ov2650) sensor subdev driver. > 5. Intel Moorestown 1.3MP camera (ov9665) sensor subdev driver. > 6. Intel Moorestown 5MP camera (ov5630) sensor subdev driver. > 7. Intel Moorestown 5MP camera (ov5630) lens subdev driver. > 8. Intel Moorestown 5MP camera (s5k4e1) sensor subdev driver. > 9. Intel Moorestown 5MP camera (s5k4e1) lens subdev driver > 10. make/kconfig files change to enable camera drivers for intel Moorestown > platform. > > Please review them and comments are welcome as always. > > Regards, > > Xiaolin > xiaolin.zh...@intel.com > -- > 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 > > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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] video/cx231xx: cleanup. remove unneed null checks
"dev" is never NULL here so there is no need to check. Signed-off-by: Dan Carpenter diff --git a/drivers/media/video/cx231xx/cx231xx-core.c b/drivers/media/video/cx231xx/cx231xx-core.c index 4a60dfb..866fb12 100644 --- a/drivers/media/video/cx231xx/cx231xx-core.c +++ b/drivers/media/video/cx231xx/cx231xx-core.c @@ -95,10 +95,9 @@ int cx231xx_register_extension(struct cx231xx_ops *ops) mutex_lock(&cx231xx_devlist_mutex); mutex_lock(&cx231xx_extension_devlist_lock); list_add_tail(&ops->next, &cx231xx_extension_devlist); - list_for_each_entry(dev, &cx231xx_devlist, devlist) { - if (dev) - ops->init(dev); - } + list_for_each_entry(dev, &cx231xx_devlist, devlist) + ops->init(dev); + printk(KERN_INFO DRIVER_NAME ": %s initialized\n", ops->name); mutex_unlock(&cx231xx_extension_devlist_lock); mutex_unlock(&cx231xx_devlist_mutex); @@ -111,10 +110,8 @@ void cx231xx_unregister_extension(struct cx231xx_ops *ops) struct cx231xx *dev = NULL; mutex_lock(&cx231xx_devlist_mutex); - list_for_each_entry(dev, &cx231xx_devlist, devlist) { - if (dev) - ops->fini(dev); - } + list_for_each_entry(dev, &cx231xx_devlist, devlist) + ops->fini(dev); mutex_lock(&cx231xx_extension_devlist_lock); printk(KERN_INFO DRIVER_NAME ": %s removed\n", ops->name); -- 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] video/s255drv: cleanup. remove uneeded NULL check
"dev" can never be NULL there so there is no need to check it. Also I made a couple of white space changes to the declaration of "dev". This eliminates a smatch warning about checking for NULL after a dereference. Signed-off-by: Dan Carpenter diff --git a/drivers/media/video/s2255drv.c b/drivers/media/video/s2255drv.c index fb742f1..e70af5d 100644 --- a/drivers/media/video/s2255drv.c +++ b/drivers/media/video/s2255drv.c @@ -2582,8 +2582,9 @@ error: /* disconnect routine. when board is removed physically or with rmmod */ static void s2255_disconnect(struct usb_interface *interface) { - struct s2255_dev *dev = NULL; + struct s2255_dev *dev; int i; + dprintk(1, "s2255: disconnect interface %p\n", interface); dev = usb_get_intfdata(interface); @@ -2602,11 +2603,9 @@ static void s2255_disconnect(struct usb_interface *interface) usb_set_intfdata(interface, NULL); mutex_unlock(&dev->open_lock); - if (dev) { - kref_put(&dev->kref, s2255_destroy); - dprintk(1, "s2255drv: disconnect\n"); - dev_info(&interface->dev, "s2255usb now disconnected\n"); - } + kref_put(&dev->kref, s2255_destroy); + dprintk(1, "s2255drv: disconnect\n"); + dev_info(&interface->dev, "s2255usb now disconnected\n"); } static struct usb_driver s2255_driver = { -- 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] video/au0828: off by one bug
The "AUVI_INPUT(tmp)" macro uses "tmp" as an index of an array with AU0828_MAX_INPUT elements. Signed-off-by: Dan Carpenter diff --git a/drivers/media/video/au0828/au0828-video.c b/drivers/media/video/au0828/au0828-video.c index dc67bc4..19a5773 100644 --- a/drivers/media/video/au0828/au0828-video.c +++ b/drivers/media/video/au0828/au0828-video.c @@ -1104,7 +1104,7 @@ static int vidioc_enum_input(struct file *file, void *priv, tmp = input->index; - if (tmp > AU0828_MAX_INPUT) + if (tmp >= AU0828_MAX_INPUT) return -EINVAL; if (AUVI_INPUT(tmp).type == 0) return -EINVAL; -- 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
Hauppauge WinTV HVR-900H
Hello linux-media, I've recently bought an HVR-900H usb hybrid tuner (marketed as 900-without-h) and discovered that it's been unsupported for a while now. Nevertheless some work is being done there: http://www.mail-archive.com/linux-media@vger.kernel.org/msg16498.html I've tried the patch (with linux 2.6.32) and I got as far as the firmware being uploaded, but when I tried playing some TV it crashed the kernel. I'm willing to help speeding up the driver development, so I was wondering if there's anything I can start with (like testing). Hopefully I'll be able to do some development later on, but I've got a lot of reading ahead before this could happen. Oh, yes - the device id is 2040:6600. Regards George -- 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
What would be a good time to move subdev drivers to a subdev directory?
Hi Mauro, Currently drivers/media/video is a mix of subdev drivers and bridge/platform drivers. I think it would be good to create a drivers/media/subdev directory where subdev drivers can go. We discussed in the past whether we should have categories for audio subdevs, video subdevs, etc. but I think that will cause problems, especially with future multifunction devices. What is your opinion on this, and what would be a good time to start moving drivers? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
[GIT PATCHES FOR 2.6.35] saa7134 empress improvements
The following changes since commit 942ab4762505a51a7a433a7608ba5d3eed6e4f8b: Jean Delvare (1): V4L/DVB: saa7134: Fix IR support of some ASUS TV-FM 7135 variants are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git saa6752hs Hans Verkuil (2): saa7134/saa6752hs: improve saa6752hs initialization sequence saa7134-empress: enable the saa6752hs at the right places drivers/media/video/saa7134/saa6752hs.c | 21 +++-- drivers/media/video/saa7134/saa7134-core.c| 18 +-- drivers/media/video/saa7134/saa7134-empress.c | 39 - include/media/saa6752hs.h | 15 ++ 4 files changed, 61 insertions(+), 32 deletions(-) Tested with the Behold TV M6 card. These changes will make it easier for Dmitri to implement support for the new uPD61151 encoder. There are still ugly bits in this code. For example, there is really no reason why the MPEG video device node cannot be opened multiple times. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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 4/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers
Hi Xiaolin! The comments I make here also apply to all the other subdev drivers you posted. On Sunday 28 March 2010 09:47:28 Zhang, Xiaolin wrote: > From f09b86fb073db95eaeefb1e9ffb4e448e6359bd3 Mon Sep 17 00:00:00 2001 > From: Xiaolin Zhang > Date: Sun, 28 Mar 2010 14:01:01 +0800 > Subject: [PATCH 04/10] this patch is 2mp camera (ov2650) sensor subdev driver > for intel moorestown camera imaging. > > Signed-off-by: Xiaolin Zhang > --- > drivers/media/video/mrstci/mrstov2650/Kconfig |9 + > drivers/media/video/mrstci/mrstov2650/Makefile |3 + > drivers/media/video/mrstci/mrstov2650/mrstov2650.c | 772 > > drivers/media/video/mrstci/mrstov2650/ov2650.h | 717 ++ > 4 files changed, 1501 insertions(+), 0 deletions(-) > create mode 100644 drivers/media/video/mrstci/mrstov2650/Kconfig > create mode 100644 drivers/media/video/mrstci/mrstov2650/Makefile > create mode 100644 drivers/media/video/mrstci/mrstov2650/mrstov2650.c > create mode 100644 drivers/media/video/mrstci/mrstov2650/ov2650.h > > diff --git a/drivers/media/video/mrstci/mrstov2650/Kconfig > b/drivers/media/video/mrstci/mrstov2650/Kconfig > new file mode 100644 > index 000..d39d894 > --- /dev/null > +++ b/drivers/media/video/mrstci/mrstov2650/Kconfig > @@ -0,0 +1,9 @@ > +config VIDEO_MRST_OV2650 > + tristate "Moorestown OV2650 SoC Sensor" > + depends on I2C && VIDEO_MRST_ISP These i2c devices are not an integral part of Moorestown, are they? These are i2c devices that can also be found in other products. So they should not depend on Moorestown and the drivers should be placed in drivers/media/video and any references to Moorestown should be removed. > + > + ---help--- > + Say Y here if your platform support OV2650 SoC Sensor. > + > + To compile this driver as a module, choose M here: the > + module will be called mrstov2650.ko. > diff --git a/drivers/media/video/mrstci/mrstov2650/Makefile > b/drivers/media/video/mrstci/mrstov2650/Makefile > new file mode 100644 > index 000..fb16d57 > --- /dev/null > +++ b/drivers/media/video/mrstci/mrstov2650/Makefile > @@ -0,0 +1,3 @@ > +obj-$(CONFIG_VIDEO_MRST_OV2650) += mrstov2650.o > + > +EXTRA_CFLAGS += -I$(src)/../include > \ No newline at end of file > diff --git a/drivers/media/video/mrstci/mrstov2650/mrstov2650.c > b/drivers/media/video/mrstci/mrstov2650/mrstov2650.c > new file mode 100644 > index 000..84aee57 > --- /dev/null > +++ b/drivers/media/video/mrstci/mrstov2650/mrstov2650.c > @@ -0,0 +1,772 @@ > +/* > + * Support for Moorestown Langwell Camera Imaging ISP subsystem. > + * > + * Copyright (c) 2009 Intel Corporation. All Rights Reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License version > + * 2 as published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA > + * 02110-1301, USA. > + * > + * > + * Xiaolin Zhang > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include Please prune this list of includes. Things like delay, gpio, slab, fs and no doubt more are not needed. > +#include > +#include > +#include > +#include Don't use this header! It is for backwards compatibility of older i2c drivers and should not be used with modern drivers. See for example tvp514x.c on how to implement this without using v4l2-i2c-drv.h. > + > +#include "ci_sensor_common.h" > +#include "ov2650.h" > + > +static int mrstov2650_debug; > +module_param(mrstov2650_debug, int, 0644); > +MODULE_PARM_DESC(mrstov2650_debug, "Debug level (0-1)"); > + > +#define dprintk(level, fmt, arg...) do { \ > + if (mrstov2650_debug >= level) \ > + printk(KERN_DEBUG "mrst...@%s: " fmt "\n", \ > + __func__, ## arg); } \ > + while (0) > + > +#define eprintk(fmt, arg...) \ > + printk(KERN_ERR "mrst...@%s: line %d: " fmt "\n", \ > + __func__, __LINE__, ## arg); > + > +#define DBG_entering dprintk(2, "entering"); > +#define DBG_leavingdprintk(2, "leaving"); > +#define DBG_line dprintk(2, " line: %d", __LINE__); As mentioned in the comments in patch 0/10 I think debug constructions like this probably should just be removed. > + > +static inline struct ci_
Re: [PATCH v2 3/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers
Hi Xiaolin! I found a small memory leak in this flash driver: On Sunday 28 March 2010 09:47:21 Zhang, Xiaolin wrote: > +static int flash_remove(struct i2c_client *client) > +{ > + struct v4l2_subdev *sd = i2c_get_clientdata(client); > + > + v4l2_device_unregister_subdev(sd); Missing kfree(sd). > + > + return 0; > +} -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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 0/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers
Hi Xiaolin! Here are a few comments based on a first read-through. First of all, patch 2/10 did not seem to make it to the list for some reason. Because of that I'm deferring reviewing patches 1/10 and (of course) 2/10. The other patches for the i2c devices all have the same problems, so I will only review one and you can apply the comments made there to all the others. A general comment I have is that I think there is too much debugging code. Creating good debug code is an art. In my experience things like DBG_entering and DBG_leaving just clutter the code and are pretty useless once the initial implementation phase is finished. The trick is to have just enough debug or logging available so that you can deduce the path taken by the driver. What I found to be very useful as well is to implement VIDIOC_LOG_STATUS to get a full status overview of the various (sub)devices at a given moment. On Sunday 28 March 2010 09:46:35 Zhang, Xiaolin wrote: > Hi, > > Here is the second version of V4L2 camera sensors and ISP driver patch set to > support the Intel Moorestown camera imaging subsystem. > > The Camera Imaging interface (CI) in Moorestown is responsible for still > image and video capture which can handle demosaicing, color synthesis, > filtering, image enhancement, etc functionalities with a integrated JPEG > encode. > Intel Moorestown platform can support either a single camera or dual cameras. > If a platform with dual camera will have one low resolution camera on the > same side as this display for video conference and a high resolution camera > on the opposite side the display for high quality still image capture. > > The driver framework is updated to the v4l2 sub-dev and video buffer > framework, in this set of driver patches, I will submit the 10 patches to > enable the camera subsystem with the device drivers for ISP HW and 4 cameras > module (two SoCs: 1.3MP - Omnivision 9665, 2MP - Omnivison 2650 and two RAWs: > 5MP - Omnivision 5630, 5MP - Samsong s5k4e1). > > 1. Intel Moorestown ISP driver - header files. Just a single comment on these files here: I see new PIXFMT defines in a Moorestown-specific header: just add these to videodev2.h. Regards, Hans > 2. Intel Moorestown ISP driver - V4L2 implementation including hardware > component functionality > 3. Intel Moorestown flash sub-dev driver > 4. Intel Moorestown 2MP camera (ov2650) sensor subdev driver. > 5. Intel Moorestown 1.3MP camera (ov9665) sensor subdev driver. > 6. Intel Moorestown 5MP camera (ov5630) sensor subdev driver. > 7. Intel Moorestown 5MP camera (ov5630) lens subdev driver. > 8. Intel Moorestown 5MP camera (s5k4e1) sensor subdev driver. > 9. Intel Moorestown 5MP camera (s5k4e1) lens subdev driver > 10. make/kconfig files change to enable camera drivers for intel Moorestown > platform. > > Please review them and comments are welcome as always. > > Regards, > > Xiaolin > xiaolin.zh...@intel.com > -- > 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 > > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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 v2 10/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers
>From 166299cfa17bb5e16613eff962cce841d2c15f0f Mon Sep 17 00:00:00 2001 From: Xiaolin Zhang Date: Sun, 28 Mar 2010 14:19:12 +0800 Subject: [PATCH 10/10] this patch is the make/kconfig files changes to enable the camera drivers for intel moorestown platform. Signed-off-by: Xiaolin Zhang --- drivers/media/video/Kconfig |1 + drivers/media/video/Makefile|9 + drivers/media/video/mrstci/Kconfig | 26 ++ drivers/media/video/mrstci/Makefile |8 4 files changed, 44 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mrstci/Kconfig create mode 100644 drivers/media/video/mrstci/Makefile diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index dcf9fa9..1b3726f 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -954,4 +954,5 @@ config USB_S2255 This driver can be compiled as a module, called s2255drv. endif # V4L_USB_DRIVERS +source "drivers/media/video/mrstci/Kconfig" endif # VIDEO_CAPTURE_DRIVERS diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 9f2e321..6a4b5ff 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -160,6 +160,15 @@ obj-$(CONFIG_USB_VIDEO_CLASS) += uvc/ obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o +obj-$(CONFIG_VIDEO_MRST_OV2650) += mrstci/mrstov2650/ +obj-$(CONFIG_VIDEO_MRST_OV5630) += mrstci/mrstov5630/ +obj-$(CONFIG_VIDEO_MRST_OV5630_MOTOR) += mrstci/mrstov5630_motor/ +obj-$(CONFIG_VIDEO_MRST_S5K4E1) += mrstci/mrsts5k4e1/ +obj-$(CONFIG_VIDEO_MRST_S5K4E1_MOTOR) += mrstci/mrsts5k4e1_motor/ +obj-$(CONFIG_VIDEO_MRST_OV9665) += mrstci/mrstov9665/ +obj-$(CONFIG_VIDEO_MRST_FLASH) += mrstci/mrstflash/ +obj-$(CONFIG_VIDEO_MRST_ISP) += mrstci/mrstisp/ + EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core EXTRA_CFLAGS += -Idrivers/media/dvb/frontends EXTRA_CFLAGS += -Idrivers/media/common/tuners diff --git a/drivers/media/video/mrstci/Kconfig b/drivers/media/video/mrstci/Kconfig new file mode 100644 index 000..9ac7065 --- /dev/null +++ b/drivers/media/video/mrstci/Kconfig @@ -0,0 +1,26 @@ +menuconfig VIDEO_MRSTCI +bool "Moorestown Langwell Camera Imaging Subsystem support" +depends on VIDEO_V4L2 +default y + +---help--- + Say Y here to enable selecting the Intel Moorestown Langwell Camera Imaging Subsystem for webcams. + +if VIDEO_MRSTCI && VIDEO_V4L2 + +source "drivers/media/video/mrstci/mrstisp/Kconfig" + +source "drivers/media/video/mrstci/mrstov5630/Kconfig" +source "drivers/media/video/mrstci/mrstov5630_motor/Kconfig" + +source "drivers/media/video/mrstci/mrsts5k4e1/Kconfig" +source "drivers/media/video/mrstci/mrsts5k4e1_motor/Kconfig" + +source "drivers/media/video/mrstci/mrstflash/Kconfig" + +source "drivers/media/video/mrstci/mrstov2650/Kconfig" + +source "drivers/media/video/mrstci/mrstov9665/Kconfig" + +endif # VIDEO_MRSTCI + diff --git a/drivers/media/video/mrstci/Makefile b/drivers/media/video/mrstci/Makefile new file mode 100644 index 000..9d3449e --- /dev/null +++ b/drivers/media/video/mrstci/Makefile @@ -0,0 +1,8 @@ +obj-$(CONFIG_VIDEO_MRST_OV2650) += mrstov2650/ +obj-$(CONFIG_VIDEO_MRST_OV9665) += mrstov9665/ +obj-$(CONFIG_VIDEO_MRST_OV5630) += mrstov5630/ +obj-$(CONFIG_VIDEO_MRST_OV5630_MOTOR) += mrstov5630_motor/ +obj-$(CONFIG_VIDEO_MRST_S5K4E1) += mrsts5k4e1/ +obj-$(CONFIG_VIDEO_MRST_S5K4E1_MOTOR) += mrsts5k4e1_motor/ +obj-$(CONFIG_VIDEO_MRST_FLASH) += mrstflash/ +obj-$(CONFIG_VIDEO_MRST_ISP) += mrstisp/ -- 1.6.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 8/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers
>From 7ecf6eb90a22901c6550a2392967d911c611690c Mon Sep 17 00:00:00 2001 From: Xiaolin Zhang Date: Sun, 28 Mar 2010 14:14:29 +0800 Subject: [PATCH 08/10] this patch is the 5mp camera (s5k4e1) sensor subdev driver for intel moorestown camera imaging. Signed-off-by: Xiaolin Zhang --- drivers/media/video/mrstci/mrsts5k4e1/Kconfig |9 + drivers/media/video/mrstci/mrsts5k4e1/Makefile |3 + drivers/media/video/mrstci/mrsts5k4e1/mrsts5k4e1.c | 861 drivers/media/video/mrstci/mrsts5k4e1/mrsts5k4e1.h | 573 + 4 files changed, 1446 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mrstci/mrsts5k4e1/Kconfig create mode 100644 drivers/media/video/mrstci/mrsts5k4e1/Makefile create mode 100644 drivers/media/video/mrstci/mrsts5k4e1/mrsts5k4e1.c create mode 100644 drivers/media/video/mrstci/mrsts5k4e1/mrsts5k4e1.h diff --git a/drivers/media/video/mrstci/mrsts5k4e1/Kconfig b/drivers/media/video/mrstci/mrsts5k4e1/Kconfig new file mode 100644 index 000..7dee787 --- /dev/null +++ b/drivers/media/video/mrstci/mrsts5k4e1/Kconfig @@ -0,0 +1,9 @@ +config VIDEO_MRST_S5K4E1 + tristate "Moorestown s5k4e1 RAW Sensor" + depends on I2C && VIDEO_MRST_ISP + + ---help--- + Say Y here if your platform support s5k4e1 RAW Sensor. + + To compile this driver as a module, choose M here: the + module will be called mrstov2650.ko. diff --git a/drivers/media/video/mrstci/mrsts5k4e1/Makefile b/drivers/media/video/mrstci/mrsts5k4e1/Makefile new file mode 100644 index 000..8733fa8 --- /dev/null +++ b/drivers/media/video/mrstci/mrsts5k4e1/Makefile @@ -0,0 +1,3 @@ +obj-$(CONFIG_VIDEO_MRST_S5K4E1) += mrsts5k4e1.o + +EXTRA_CFLAGS += -I$(src)/../include diff --git a/drivers/media/video/mrstci/mrsts5k4e1/mrsts5k4e1.c b/drivers/media/video/mrstci/mrsts5k4e1/mrsts5k4e1.c new file mode 100644 index 000..1c31872 --- /dev/null +++ b/drivers/media/video/mrstci/mrsts5k4e1/mrsts5k4e1.c @@ -0,0 +1,861 @@ +/* + * Support for Moorestown Langwell Camera Imaging ISP subsystem. + * + * Copyright (c) 2009 Intel Corporation. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version + * 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + * 02110-1301, USA. + * + * + * Xiaolin Zhang + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include "ci_sensor_common.h" +#include "mrsts5k4e1.h" + +static int s5k4e1_debug; +module_param(s5k4e1_debug, int, 0644); +MODULE_PARM_DESC(s5k4e1_debug, "Debug level (0-1)"); + +#define dprintk(level, fmt, arg...) \ + do { \ + if (s5k4e1_debug >= level) \ + printk(KERN_DEBUG "mrst...@%s: " fmt "\n", \ + __func__, ## arg);\ + } while (0) + +#define eprintk(fmt, arg...) \ + printk(KERN_ERR "mrst...@%s:" fmt "\n", \ + __func__, ## arg); + +#define DBG_entering dprintk(1, "entering"); +#define DBG_leavingdprintk(1, "leaving"); +#define DBG_line dprintk(1, " line: %d", __LINE__); + +static inline struct ci_sensor_config *to_sensor_config(struct v4l2_subdev *sd) +{ + return container_of(sd, struct ci_sensor_config, sd); +} + +static struct s5k4e1_format_struct { + __u8 *desc; + __u32 pixelformat; + struct regval_list *regs; +} s5k4e1_formats[] = { + { + .desc = "Raw RGB Bayer", + .pixelformat= SENSOR_MODE_MIPI, + .regs = NULL, + }, +}; +#define N_S5K4E1_FMTS ARRAY_SIZE(s5k4e1_formats) + +static struct s5k4e1_res_struct { + __u8 *desc; + int res; + int width; + int height; + int fps; + bool used; + struct regval_list *regs; +} s5k4e1_res[] = { + { + .desc = "QSXGA_PLUS4", + .res= SENSOR_RES_QXGA_PLUS, + .width = 2592, + .height = 1944, + .fps= 15, + .used = 0, + .regs = s5k4e1_res_qsxga_plus4, + }, + { + .desc = "1080P", + .res= SENSOR_RES_1080P, + .width = 1920, +
[PATCH v2 7/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers
>From ffd8b7e0f07391e9d44bd0c93390362fca0e6a2f Mon Sep 17 00:00:00 2001 From: Xiaolin Zhang Date: Sun, 28 Mar 2010 14:12:41 +0800 Subject: [PATCH 07/10] this patch is the 5mp camera (ov5630) sensor lens subdev driver for intel moorestown camera imaging. Signed-off-by: Xiaolin Zhang --- .../media/video/mrstci/mrstov5630_motor/Kconfig|9 + .../media/video/mrstci/mrstov5630_motor/Makefile |3 + .../mrstci/mrstov5630_motor/mrstov5630_motor.c | 373 .../video/mrstci/mrstov5630_motor/ov5630_motor.h | 89 + 4 files changed, 474 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mrstci/mrstov5630_motor/Kconfig create mode 100644 drivers/media/video/mrstci/mrstov5630_motor/Makefile create mode 100644 drivers/media/video/mrstci/mrstov5630_motor/mrstov5630_motor.c create mode 100644 drivers/media/video/mrstci/mrstov5630_motor/ov5630_motor.h diff --git a/drivers/media/video/mrstci/mrstov5630_motor/Kconfig b/drivers/media/video/mrstci/mrstov5630_motor/Kconfig new file mode 100644 index 000..b6dcf62 --- /dev/null +++ b/drivers/media/video/mrstci/mrstov5630_motor/Kconfig @@ -0,0 +1,9 @@ +config VIDEO_MRST_OV5630_MOTOR + tristate "Moorestown OV5630 motor" + depends on I2C && VIDEO_MRST_ISP && VIDEO_MRST_OV5630 + + ---help--- + Say Y here if your platform support OV5630 motor + + To compile this driver as a module, choose M here: the + module will be called mrstov2650.ko. diff --git a/drivers/media/video/mrstci/mrstov5630_motor/Makefile b/drivers/media/video/mrstci/mrstov5630_motor/Makefile new file mode 100644 index 000..056b2a6 --- /dev/null +++ b/drivers/media/video/mrstci/mrstov5630_motor/Makefile @@ -0,0 +1,3 @@ +obj-$(CONFIG_VIDEO_MRST_OV2650) += mrstov5630_motor.o + +EXTRA_CFLAGS += -I$(src)/../include diff --git a/drivers/media/video/mrstci/mrstov5630_motor/mrstov5630_motor.c b/drivers/media/video/mrstci/mrstov5630_motor/mrstov5630_motor.c new file mode 100644 index 000..ef26985 --- /dev/null +++ b/drivers/media/video/mrstci/mrstov5630_motor/mrstov5630_motor.c @@ -0,0 +1,373 @@ +/* + * Support for Moorestown Langwell Camera Imaging ISP subsystem. + * + * Copyright (c) 2009 Intel Corporation. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version + * 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + * 02110-1301, USA. + * + * + * Xiaolin Zhang + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include "ov5630_motor.h" + +static int mrstov5630_motor_debug; +module_param(mrstov5630_motor_debug, int, 0644); +MODULE_PARM_DESC(mrstov5630_motor_debug, "Debug level (0-1)"); + +#define dprintk(level, fmt, arg...) do { \ + if (mrstov5630_motor_debug >= level)\ + printk(KERN_DEBUG "mrst...@%s: " fmt "\n", \ + __func__, ## arg); } \ + while (0) + +#define eprintk(fmt, arg...) \ + printk(KERN_ERR "mrst...@%s: line %d: " fmt "\n", \ + __func__, __LINE__, ## arg); + +#define DBG_entering dprintk(2, "entering"); +#define DBG_leavingdprintk(2, "leaving"); +#define DBG_line dprintk(2, " line: %d", __LINE__); + +static inline struct ov5630_motor *to_motor_config(struct v4l2_subdev *sd) +{ + return container_of(sd, struct ov5630_motor, sd); +} + +static int motor_read(struct i2c_client *c, u16 *reg) +{ + int ret; + struct i2c_msg msg; + u8 msgbuf[2]; + + msgbuf[0] = 0; + msgbuf[1] = 0; + + memset(&msg, 0, sizeof(msg)); + msg.addr = c->addr; + msg.buf = msgbuf; + msg.len = 2; + msg.flags = I2C_M_RD; + + ret = i2c_transfer(c->adapter, &msg, 1); + *reg = (msgbuf[0] << 8 | msgbuf[1]); + + ret = (ret == 1) ? 0 : -1; + return ret; +} + +static int motor_write(struct i2c_client *c, u16 reg) +{ + int ret; + struct i2c_msg msg; + u8 msgbuf[2]; + + memset(&msg, 0, sizeof(msg)); + msgbuf[0] = reg >> 8; + msgbuf[1] = reg; + + msg.addr = c->addr; + msg.flags = 0; + msg.buf = msgbuf; + msg.len = 2; + + ret = i2c_transfer(c->adapter, &msg, 1); + ret = (ret == 1) ? 0 : -1; + return
[PATCH v2 4/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers
>From f09b86fb073db95eaeefb1e9ffb4e448e6359bd3 Mon Sep 17 00:00:00 2001 From: Xiaolin Zhang Date: Sun, 28 Mar 2010 14:01:01 +0800 Subject: [PATCH 04/10] this patch is 2mp camera (ov2650) sensor subdev driver for intel moorestown camera imaging. Signed-off-by: Xiaolin Zhang --- drivers/media/video/mrstci/mrstov2650/Kconfig |9 + drivers/media/video/mrstci/mrstov2650/Makefile |3 + drivers/media/video/mrstci/mrstov2650/mrstov2650.c | 772 drivers/media/video/mrstci/mrstov2650/ov2650.h | 717 ++ 4 files changed, 1501 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mrstci/mrstov2650/Kconfig create mode 100644 drivers/media/video/mrstci/mrstov2650/Makefile create mode 100644 drivers/media/video/mrstci/mrstov2650/mrstov2650.c create mode 100644 drivers/media/video/mrstci/mrstov2650/ov2650.h diff --git a/drivers/media/video/mrstci/mrstov2650/Kconfig b/drivers/media/video/mrstci/mrstov2650/Kconfig new file mode 100644 index 000..d39d894 --- /dev/null +++ b/drivers/media/video/mrstci/mrstov2650/Kconfig @@ -0,0 +1,9 @@ +config VIDEO_MRST_OV2650 + tristate "Moorestown OV2650 SoC Sensor" + depends on I2C && VIDEO_MRST_ISP + + ---help--- + Say Y here if your platform support OV2650 SoC Sensor. + + To compile this driver as a module, choose M here: the + module will be called mrstov2650.ko. diff --git a/drivers/media/video/mrstci/mrstov2650/Makefile b/drivers/media/video/mrstci/mrstov2650/Makefile new file mode 100644 index 000..fb16d57 --- /dev/null +++ b/drivers/media/video/mrstci/mrstov2650/Makefile @@ -0,0 +1,3 @@ +obj-$(CONFIG_VIDEO_MRST_OV2650) += mrstov2650.o + +EXTRA_CFLAGS += -I$(src)/../include \ No newline at end of file diff --git a/drivers/media/video/mrstci/mrstov2650/mrstov2650.c b/drivers/media/video/mrstci/mrstov2650/mrstov2650.c new file mode 100644 index 000..84aee57 --- /dev/null +++ b/drivers/media/video/mrstci/mrstov2650/mrstov2650.c @@ -0,0 +1,772 @@ +/* + * Support for Moorestown Langwell Camera Imaging ISP subsystem. + * + * Copyright (c) 2009 Intel Corporation. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version + * 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + * 02110-1301, USA. + * + * + * Xiaolin Zhang + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "ci_sensor_common.h" +#include "ov2650.h" + +static int mrstov2650_debug; +module_param(mrstov2650_debug, int, 0644); +MODULE_PARM_DESC(mrstov2650_debug, "Debug level (0-1)"); + +#define dprintk(level, fmt, arg...) do { \ + if (mrstov2650_debug >= level) \ + printk(KERN_DEBUG "mrst...@%s: " fmt "\n", \ + __func__, ## arg); } \ + while (0) + +#define eprintk(fmt, arg...) \ + printk(KERN_ERR "mrst...@%s: line %d: " fmt "\n", \ + __func__, __LINE__, ## arg); + +#define DBG_entering dprintk(2, "entering"); +#define DBG_leavingdprintk(2, "leaving"); +#define DBG_line dprintk(2, " line: %d", __LINE__); + +static inline struct ci_sensor_config *to_sensor_config(struct v4l2_subdev *sd) +{ + return container_of(sd, struct ci_sensor_config, sd); +} + +static struct ov2650_format_struct { + __u8 *desc; + __u32 pixelformat; + struct regval_list *regs; +} ov2650_formats[] = { + { + .desc = "YUYV 4:2:2", + .pixelformat= SENSOR_MODE_BT601, + .regs = NULL, + }, +}; +#define N_OV2650_FMTS ARRAY_SIZE(ov2650_formats) + +static struct ov2650_res_struct { + __u8 *desc; + int res; + int width; + int height; + int fps; + bool used; + struct regval_list *regs; +} ov2650_res[] = { + { + .desc = "UXGA", + .res= SENSOR_RES_UXGA, + .width = 1600, + .height = 1200, + .fps= 15, + .used = 0, + .regs = ov2650_res_uxga, + }, + { + .desc = "SXGA", + .res= SE
[PATCH v2 6/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers
>From 9b6d236769ebd30005c0160538df56f940b159b1 Mon Sep 17 00:00:00 2001 From: Xiaolin Zhang Date: Sun, 28 Mar 2010 14:08:04 +0800 Subject: [PATCH 06/10] this patch is the 5mp camera (ov5630) sensor subdev driver for intel moorestown imaging. Signed-off-by: Xiaolin Zhang --- drivers/media/video/mrstci/mrstov5630/Kconfig |9 + drivers/media/video/mrstci/mrstov5630/Makefile |4 + drivers/media/video/mrstci/mrstov5630/ov5630.c | 832 drivers/media/video/mrstci/mrstov5630/ov5630.h | 635 ++ 4 files changed, 1480 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mrstci/mrstov5630/Kconfig create mode 100644 drivers/media/video/mrstci/mrstov5630/Makefile create mode 100644 drivers/media/video/mrstci/mrstov5630/ov5630.c create mode 100644 drivers/media/video/mrstci/mrstov5630/ov5630.h diff --git a/drivers/media/video/mrstci/mrstov5630/Kconfig b/drivers/media/video/mrstci/mrstov5630/Kconfig new file mode 100644 index 000..a28ddc2 --- /dev/null +++ b/drivers/media/video/mrstci/mrstov5630/Kconfig @@ -0,0 +1,9 @@ +config VIDEO_MRST_OV5630 + tristate "Moorestown OV5630 RAW Sensor" + depends on I2C && VIDEO_MRST_ISP + + ---help--- + Say Y here if your platform support OV5630 RAW Sensor. + + To compile this driver as a module, choose M here: the + module will be called mrstov2650.ko. diff --git a/drivers/media/video/mrstci/mrstov5630/Makefile b/drivers/media/video/mrstci/mrstov5630/Makefile new file mode 100644 index 000..c67abff --- /dev/null +++ b/drivers/media/video/mrstci/mrstov5630/Makefile @@ -0,0 +1,4 @@ +mrstov5630-objs= ov5630.o +obj-$(CONFIG_VIDEO_MRST_OV5630) += mrstov5630.o + +EXTRA_CFLAGS += -I$(src)/../include diff --git a/drivers/media/video/mrstci/mrstov5630/ov5630.c b/drivers/media/video/mrstci/mrstov5630/ov5630.c new file mode 100644 index 000..bf91e0b --- /dev/null +++ b/drivers/media/video/mrstci/mrstov5630/ov5630.c @@ -0,0 +1,832 @@ +/* + * Support for Moorestown Langwell Camera Imaging ISP subsystem. + * + * Copyright (c) 2009 Intel Corporation. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version + * 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + * 02110-1301, USA. + * + * + * Xiaolin Zhang + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include "ci_sensor_common.h" +#include "ov5630.h" + +static int mrstov5630_debug; +module_param(mrstov5630_debug, int, 0644); +MODULE_PARM_DESC(mrstov5630_debug, "Debug level (0-1)"); + +#define dprintk(level, fmt, arg...) do { \ + if (mrstov5630_debug >= level) \ + printk(KERN_DEBUG "mrst...@%s: " fmt "\n", \ + __func__, ## arg); } \ + while (0) + +#define eprintk(fmt, arg...) \ + printk(KERN_ERR "mrst...@%s: line %d: " fmt "\n", \ + __func__, __LINE__, ## arg); + +#define DBG_entering dprintk(2, "entering"); +#define DBG_leavingdprintk(2, "leaving"); +#define DBG_line dprintk(2, " line: %d", __LINE__); + +static inline struct ci_sensor_config *to_sensor_config(struct v4l2_subdev *sd) +{ + return container_of(sd, struct ci_sensor_config, sd); +} + +static struct ov5630_format_struct { + __u8 *desc; + __u32 pixelformat; + struct regval_list *regs; +} ov5630_formats[] = { + { + .desc = "Raw RGB Bayer", + .pixelformat= SENSOR_MODE_BAYER, + .regs = NULL, + }, +}; +#define N_OV5630_FMTS ARRAY_SIZE(ov5630_formats) + +static struct ov5630_res_struct { + __u8 *desc; + int res; + int width; + int height; + int fps; + bool used; + struct regval_list *regs; +} ov5630_res[] = { + { + .desc = "QSXGA_PLUS4", + .res= SENSOR_RES_QXGA_PLUS, + .width = 2592, + .height = 1944, + .fps= 15, + .used = 0, + .regs = ov5630_res_qsxga_plus4, + }, + { + .desc = "1080P", + .res= SENSOR_
[PATCH v2 5/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers
>From 51bb9c1b42f8c92a5b01cdd24141ac1117a4c076 Mon Sep 17 00:00:00 2001 From: Xiaolin Zhang Date: Sun, 28 Mar 2010 14:03:26 +0800 Subject: [PATCH 05/10] this patch is the 1.3mp camera (ov9665) sensor subdev driver fro interl moorestown camera imaging. Signed-off-by: Xiaolin Zhang --- drivers/media/video/mrstci/mrstov9665/Kconfig |9 + drivers/media/video/mrstci/mrstov9665/Makefile |3 + drivers/media/video/mrstci/mrstov9665/mrstov9665.c | 710 drivers/media/video/mrstci/mrstov9665/ov9665.h | 253 +++ 4 files changed, 975 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mrstci/mrstov9665/Kconfig create mode 100644 drivers/media/video/mrstci/mrstov9665/Makefile create mode 100644 drivers/media/video/mrstci/mrstov9665/mrstov9665.c create mode 100644 drivers/media/video/mrstci/mrstov9665/ov9665.h diff --git a/drivers/media/video/mrstci/mrstov9665/Kconfig b/drivers/media/video/mrstci/mrstov9665/Kconfig new file mode 100644 index 000..ba9b692 --- /dev/null +++ b/drivers/media/video/mrstci/mrstov9665/Kconfig @@ -0,0 +1,9 @@ +config VIDEO_MRST_OV9665 + tristate "Moorestown OV9665 SoC Sensor" + depends on I2C && VIDEO_MRST_ISP + + ---help--- + Say Y here if your platform support OV9665 SoC Sensor. + + To compile this driver as a module, choose M here: the + module will be called mrstov9665.ko. diff --git a/drivers/media/video/mrstci/mrstov9665/Makefile b/drivers/media/video/mrstci/mrstov9665/Makefile new file mode 100644 index 000..871b6bf --- /dev/null +++ b/drivers/media/video/mrstci/mrstov9665/Makefile @@ -0,0 +1,3 @@ +obj-$(CONFIG_VIDEO_MRST_OV9665) += mrstov9665.o + +EXTRA_CFLAGS += -I$(src)/../include diff --git a/drivers/media/video/mrstci/mrstov9665/mrstov9665.c b/drivers/media/video/mrstci/mrstov9665/mrstov9665.c new file mode 100644 index 000..042f699 --- /dev/null +++ b/drivers/media/video/mrstci/mrstov9665/mrstov9665.c @@ -0,0 +1,710 @@ +/* + * Support for Moorestown Langwell Camera Imaging ISP subsystem. + * + * Copyright (c) 2009 Intel Corporation. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version + * 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + * 02110-1301, USA. + * + * + * Xiaolin Zhang + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include "ci_sensor_common.h" +#include "ov9665.h" + +static int mrstov9665_debug; +module_param(mrstov9665_debug, int, 0644); +MODULE_PARM_DESC(mrstov9665_debug, "Debug level (0-1)"); + +#define dprintk(level, fmt, arg...) do { \ + if (mrstov9665_debug >= level) \ + printk(KERN_DEBUG "mrst...@%s: " fmt "\n", \ + __func__, ## arg); } \ + while (0) + +#define eprintk(fmt, arg...) \ + printk(KERN_ERR "mrst...@%s: line %d: " fmt "\n", \ + __func__, __LINE__, ## arg); + +#define DBG_entering dprintk(2, "entering"); +#define DBG_leavingdprintk(2, "leaving"); +#define DBG_line dprintk(2, " line: %d", __LINE__); + +static inline struct ci_sensor_config *to_sensor_config(struct v4l2_subdev *sd) +{ + return container_of(sd, struct ci_sensor_config, sd); +} + +static struct ov9665_format_struct { + __u8 *desc; + __u32 pixelformat; + struct regval_list *regs; +} ov9665_formats[] = { + { + .desc = "YUYV 4:2:2", + .pixelformat= SENSOR_MODE_BT601, + .regs = NULL, + }, +}; +#define N_OV9665_FMTS ARRAY_SIZE(ov9665_formats) + +static struct ov9665_res_struct { + __u8 *desc; + int res; + int width; + int height; + int fps; + bool used; + struct regval_list *regs; +} ov9665_res[] = { + { + .desc = "SXGA", + .res= SENSOR_RES_SXGA, + .width = 1280, + .height = 1024, + .fps= 15, + .used = 0, + .regs = ov9665_res_sxga, + }, + { + .desc = "VGA", + .res= SENSOR_RES_VGA, + .w
[PATCH v2 3/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers
>From 1fd72af8366c3cfb04520bbee7252a1991c878ba Mon Sep 17 00:00:00 2001 From: Xiaolin Zhang Date: Sun, 28 Mar 2010 13:57:52 +0800 Subject: [PATCH 03/10] This patch is the flash subdev driver for intel moorestown camera imaging. Signed-off-by: Xiaolin Zhang --- drivers/media/video/mrstci/mrstflash/Kconfig |9 ++ drivers/media/video/mrstci/mrstflash/Makefile|3 + drivers/media/video/mrstci/mrstflash/mrstflash.c | 150 ++ 3 files changed, 162 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mrstci/mrstflash/Kconfig create mode 100644 drivers/media/video/mrstci/mrstflash/Makefile create mode 100644 drivers/media/video/mrstci/mrstflash/mrstflash.c diff --git a/drivers/media/video/mrstci/mrstflash/Kconfig b/drivers/media/video/mrstci/mrstflash/Kconfig new file mode 100644 index 000..72099c5 --- /dev/null +++ b/drivers/media/video/mrstci/mrstflash/Kconfig @@ -0,0 +1,9 @@ +config VIDEO_MRST_FLASH + tristate "Moorestown flash" + depends on I2C && VIDEO_MRST_ISP + + ---help--- + Say Y here if your platform support moorestown flash. + + To compile this driver as a module, choose M here: the + module will be called mrstov2650.ko. diff --git a/drivers/media/video/mrstci/mrstflash/Makefile b/drivers/media/video/mrstci/mrstflash/Makefile new file mode 100644 index 000..068f638 --- /dev/null +++ b/drivers/media/video/mrstci/mrstflash/Makefile @@ -0,0 +1,3 @@ +obj-$(CONFIG_VIDEO_MRST_FLASH) += mrstflash.o + +EXTRA_CFLAGS += -I$(src)/../include diff --git a/drivers/media/video/mrstci/mrstflash/mrstflash.c b/drivers/media/video/mrstci/mrstflash/mrstflash.c new file mode 100644 index 000..89ceddc --- /dev/null +++ b/drivers/media/video/mrstci/mrstflash/mrstflash.c @@ -0,0 +1,150 @@ +/* + * Support for Moorestown Langwell Camera Imaging camera flash. + * + * Copyright (c) 2009 Intel Corporation. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version + * 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + * 02110-1301, USA. + * + * + * Xiaolin Zhang + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static int debug; +module_param(debug, bool, 0644); +MODULE_PARM_DESC(debug, "Debug level (0-1)"); + +MODULE_AUTHOR("Xiaolin Zhang "); +MODULE_DESCRIPTION("A low-level driver for mrst flash"); +MODULE_LICENSE("GPL"); + +static int flash_g_chip_ident(struct v4l2_subdev *sd, + struct v4l2_dbg_chip_ident *chip) +{ + struct i2c_client *client = v4l2_get_subdevdata(sd); + + #define V4L2_IDENT_MRST_FLASH 8248 + return v4l2_chip_ident_i2c_client(client, chip, + V4L2_IDENT_MRST_FLASH, 0); +} + +static const struct v4l2_subdev_core_ops flash_core_ops = { + .g_chip_ident = flash_g_chip_ident, +}; +static const struct v4l2_subdev_ops flash_ops = { + .core = &flash_core_ops, +}; + +static int flash_detect(struct i2c_client *client) +{ + struct i2c_adapter *adapter = client->adapter; + u8 pid; + + if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA)) + return -ENODEV; + + if (adapter->nr != 0) + return -ENODEV; + + pid = i2c_smbus_read_byte_data(client, 0x10); + if (pid == 0x18) { + printk(KERN_ERR "camera flash device found\n"); + v4l_dbg(1, debug, client, "found camera flash device"); + } else { + printk(KERN_ERR "no camera flash device found\n"); + return -ENODEV; + } + + return 0; +} + +static int flash_probe(struct i2c_client *client, + const struct i2c_device_id *id) +{ + u8 pid, ver; + int ret = -1; + struct v4l2_subdev *sd; + + v4l_info(client, "chip found @ 0x%x (%s)\n", + client->addr << 1, client->adapter->name); + + sd = kzalloc(sizeof(struct v4l2_subdev), GFP_KERNEL); + ret = flash_detect(client); + if (ret) + return -ENODEV; + + v4l2_i2c_subdev_init(sd, client, &flash_ops); + + ver = i2c_smbus_read_byte_data(client, 0x50); + v4l_dbg(1, debug, client, "detect:CST from device is 0x%x", ver); + pid = i2c_smbus_read_byte_data(c
[PATCH v2 0/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers
Hi, Here is the second version of V4L2 camera sensors and ISP driver patch set to support the Intel Moorestown camera imaging subsystem. The Camera Imaging interface (CI) in Moorestown is responsible for still image and video capture which can handle demosaicing, color synthesis, filtering, image enhancement, etc functionalities with a integrated JPEG encode. Intel Moorestown platform can support either a single camera or dual cameras. If a platform with dual camera will have one low resolution camera on the same side as this display for video conference and a high resolution camera on the opposite side the display for high quality still image capture. The driver framework is updated to the v4l2 sub-dev and video buffer framework, in this set of driver patches, I will submit the 10 patches to enable the camera subsystem with the device drivers for ISP HW and 4 cameras module (two SoCs: 1.3MP - Omnivision 9665, 2MP - Omnivison 2650 and two RAWs: 5MP - Omnivision 5630, 5MP - Samsong s5k4e1). 1. Intel Moorestown ISP driver - header files. 2. Intel Moorestown ISP driver - V4L2 implementation including hardware component functionality 3. Intel Moorestown flash sub-dev driver 4. Intel Moorestown 2MP camera (ov2650) sensor subdev driver. 5. Intel Moorestown 1.3MP camera (ov9665) sensor subdev driver. 6. Intel Moorestown 5MP camera (ov5630) sensor subdev driver. 7. Intel Moorestown 5MP camera (ov5630) lens subdev driver. 8. Intel Moorestown 5MP camera (s5k4e1) sensor subdev driver. 9. Intel Moorestown 5MP camera (s5k4e1) lens subdev driver 10. make/kconfig files change to enable camera drivers for intel Moorestown platform. Please review them and comments are welcome as always. Regards, Xiaolin xiaolin.zh...@intel.com -- 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