Re: [PATCH 07/16] ngene: CXD2099AR Common Interface driver
On Monday 17 January 2011 17:31:15 Mauro Carvalho Chehab wrote:
Em 10-01-2011 15:20, Oliver Endriss escreveu:
On Monday 10 January 2011 15:05:34 Andreas Oberritter wrote:
On 01/10/2011 10:36 AM, Oliver Endriss wrote:
From: Ralph Metzler r...@metzlerbros.de
Driver for the Common Interface Controller CXD2099AR.
Supports the CI of the cineS2 DVB-S2.
For now, data is passed through '/dev/dvb/adapterX/sec0':
- Encrypted data must be written to 'sec0'.
- Decrypted data can be read from 'sec0'.
- Setup the CAM using device 'ca0'.
Nack. In DVB API terms, sec stands for satellite equipment control,
and if I remember correctly, sec0 already existed in the first versions
of the API and that's why its leftovers can be abused by this driver.
The interfaces for writing data are dvr0 and demux0. If they don't fit
for decryption of recorded data, then they should be extended.
For decryption of live data, no new user interface needs to be created.
There was an attempt to find a solution for the problem in thread
http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html
As that discussion did not come to a final solution, and the driver is
still experimental, I left the original patch 'as is'.
Drivers that don't use the proper API should be moved to staging. Just making
them as experimental is not good enough. As this is the only issue with
this patch series, I'll be applying them and moving cxd2099 driver to staging
while we don't have a proper fix for it.
Ok.
+struct dvb_ca_en50221 *cxd2099_attach(u8 adr, void *priv, struct i2c_adapter
*i2c)
+{
+ printk(KERN_WARNING %s: driver disabled by Kconfig\n, __func__);
+ return NULL;
+}
+#endif
If staging drivers are disabled, compilation will fail with
multiple definition of `cxd2099_attach'.
The helper function must be declared as 'static inline'.
Please apply this fix:
diff --git a/drivers/staging/cxd2099/cxd2099.h
b/drivers/staging/cxd2099/cxd2099.h
index a313dc2..bed54ff 100644
--- a/drivers/staging/cxd2099/cxd2099.h
+++ b/drivers/staging/cxd2099/cxd2099.h
@@ -31,7 +31,7 @@
(defined(CONFIG_DVB_CXD2099_MODULE) defined(MODULE))
struct dvb_ca_en50221 *cxd2099_attach(u8 adr, void *priv, struct i2c_adapter
*i2c);
#else
-struct dvb_ca_en50221 *cxd2099_attach(u8 adr, void *priv, struct i2c_adapter
*i2c)
+static inline struct dvb_ca_en50221 *cxd2099_attach(u8 adr, void *priv, struct
i2c_adapter *i2c)
{
printk(KERN_WARNING %s: driver disabled by Kconfig\n, __func__);
return NULL;
--
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
--
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: OMAP3 ISP and tvp5151 driver.
Hi Laurent,
2011/1/14 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Enric,
On Thursday 13 January 2011 13:27:43 Enric Balletbò i Serra wrote:
2011/1/12 Laurent Pinchart laurent.pinch...@ideasonboard.com:
On Wednesday 12 January 2011 12:58:04 Enric Balletbò i Serra wrote:
Hi all,
As explained in my first mail I would like port the tvp515x driver to
new media framework, I'm a newbie with the v4l2 API and of course with
the new media framework API, so sorry if next questions are stupid or
trivial (please, patience with me).
My idea is follow this link schem:
---
- | | | 1
| -- | OMAP3 ISP CCDC OUTPUT |
| TVP515x | 0 | - | 0 | OMAP3 ISP CCDC --- |
| | | 2 |
---
ASCII art would look much better if you drew it in a non-proportional
font, with 80 character per line at most.
Where:
* TVP515x is /dev/v4l-subdev8 c 81 15
* OMAP3 ISP CCDC is /dev/v4l-subdev2 c 81 4
* OMAP3 ISP CCDC OUTPUT is /dev/video2 c 81 5
Then activate these links with
./media-ctl -r -l 'tvp5150 2-005c:0-OMAP3 ISP CCDC:0[1], OMAP3
ISP CCDC:1-OMAP3 ISP CCDC output:0[1]'
Resetting all links to disabled
Setting up link 16:0 - 5:0 [1]
Setting up link 5:1 - 6:0 [1]
I'm on the right way or I'm completely lost ?
That's correct.
I think the next step is adapt the tvp515x driver to new media
framework, I'm not sure how to do this, someone can give some points ?
You need to implement subdev pad operations. get_fmt and set_fmt are
required.
I configured the TVP5151 to 8-bit 4:2:3 YCbCr output format. Is 8-bit
4:2:3 YCbCr output format implemented in OMAP3 ISP CCDC ?
I suppose you mean 4:2:2. The CCDC doesn't support that yet.
Once this is done, I suppose I can test using gstreamer, for example
using something like this.
gst-launch v4l2src device=/dev/video2 ! ffmpegcolorspace !
xvimagesink
I'm right in this point ?
You need to specify the format explicitly. It must be identical to the
format configured on pad CCDC:1.
Can you give me an example using gstreamer ?
I'm not a gstreamer expert, sorry.
Running yavta I get
# ./yavta -f SGRBG10 -s 720x525 -n 4 --capture=4 --skip 3 -F /dev/video2
Device /dev/video2 opened: OMAP3 ISP CCDC output (media).
Video format set: width: 720 height: 525 buffer size: 756000
Video format: BA10 (30314142) 720x525
4 buffers requested.
length: 756000 offset: 0
Buffer 0 mapped at address 0x400f2000.
length: 756000 offset: 757760
Buffer 1 mapped at address 0x40385000.
length: 756000 offset: 1515520
Buffer 2 mapped at address 0x40466000.
length: 756000 offset: 2273280
Buffer 3 mapped at address 0x405ed000.
Unable to start streaming: 22.
Unable to dequeue buffer (22).
4 buffers released.
I know the format is not correct, but, is the Unable to start
streaming: 22 error related to the format or is related to another
problem ?
That usually means that the format configured on the video device node
(SGRBG10 720x525 in this case) is different than the format setup on the
connected subdev output (CCDC pad 1 in this case). My guess is that you
probably forgot to setup formats on the subdev pads (using media-ctl -f).
Right and solved, thanks, one little step more.
Now seems yavta is blocked dequeuing a buffer ( VIDIOC_DQBUF ), with
strace I get
$ strace ./yavta -f SGRBG10 -s 720x525 -n 1 --capture=1 -F /dev/video2
mmap2(NULL, 756000, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x4011f000
write(1, Buffer 0 mapped at address 0x401..., 39Buffer 0 mapped at
address 0x4011f000.
) = 39
ioctl(3, VIDIOC_QBUF or VT_SETACTIVATE, 0xbede36cc) = 0
ioctl(3, VIDIOC_STREAMON, 0xbede365c) = 0
gettimeofday({10879, 920196}, NULL) = 0
ioctl(3, VIDIOC_DQBUF
and the code where stops is here
ispqueue.c
913 buf = list_first_entry(queue-queue, struct isp_video_buffer, stream);
914 ret = isp_video_buffer_wait(buf, nonblocking);
Any idea ?
Thanks in advance
Enric
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP and tvp5151 driver.
Hi Enric,
On Tuesday 18 January 2011 10:20:43 Enric Balletbò i Serra wrote:
Now seems yavta is blocked dequeuing a buffer ( VIDIOC_DQBUF ), with
strace I get
$ strace ./yavta -f SGRBG10 -s 720x525 -n 1 --capture=1 -F /dev/video2
mmap2(NULL, 756000, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x4011f000
write(1, Buffer 0 mapped at address 0x401..., 39Buffer 0 mapped at
address 0x4011f000.
) = 39
ioctl(3, VIDIOC_QBUF or VT_SETACTIVATE, 0xbede36cc) = 0
ioctl(3, VIDIOC_STREAMON, 0xbede365c) = 0
gettimeofday({10879, 920196}, NULL) = 0
ioctl(3, VIDIOC_DQBUF
and the code where stops is here
ispqueue.c
913 buf = list_first_entry(queue-queue, struct isp_video_buffer, stream);
914 ret = isp_video_buffer_wait(buf, nonblocking);
Any idea ?
My guess is that the CCDC doesn't receive the amount of lines it expects.
The CCDC generates an interrupt at 2/3 of the image and another one at the
beginning of the last line. Start by checking if the ISP generates any
interrupt to the host with cat /proc/interrupts. If it doesn't, then the CCDC
receives less than 2/3 of the expected number of lines. If it does, it
probably receives between 2/3 and 3/3. You can add printk statements in
ispccdc_vd0_isr() and ispccdc_vd1_isr() to confirm this.
--
Regards,
Laurent Pinchart
--
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/PATCH v6 3/4] MFC: Add MFC 5.1 V4L2 driver
Hi,
From: Jaeryul Oh [mailto:jaeryul...@samsung.com]
Hi, Kamil
I have a comment about s5p_mfc_stop_streaming()function.
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Kamil Debski
Sent: Saturday, January 08, 2011 1:26 AM
To: linux-media@vger.kernel.org; linux-samsung-...@vger.kernel.org
Cc: m.szyprow...@samsung.com; pa...@osciak.com;
kyungmin.p...@samsung.com;
k.deb...@samsung.com; jaeryul...@samsung.com; kgene@samsung.com
Subject: [RFC/PATCH v6 3/4] MFC: Add MFC 5.1 V4L2 driver
Multi Format Codec 5.1 is capable of handling a range of video codecs
and this driver provides V4L2 interface for video decoding.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
snip
+
+/* Thou shalt stream no more. */
+static int s5p_mfc_stop_streaming(struct vb2_queue *q)
+{
+ unsigned long flags;
+ struct s5p_mfc_ctx *ctx = q-drv_priv;
+ struct s5p_mfc_dev *dev = ctx-dev;
+
+ if ((ctx-state == MFCINST_DEC_FINISHING ||
+ ctx-state == MFCINST_DEC_RUNNING)
+ dev-curr_ctx == ctx-num dev-hw_lock) {
+ ctx-state = MFCINST_DEC_ABORT;
+ s5p_mfc_wait_for_done_ctx(ctx,
S5P_FIMV_R2H_CMD_FRAME_DONE_RET,
+ 0);
+ }
+ ctx-state = MFCINST_DEC_FINISHED;
+ spin_lock_irqsave(dev-irqlock, flags);
+ s5p_mfc_error_cleanup_queue(ctx-dst_queue,
+ ctx-vq_dst);
+ s5p_mfc_error_cleanup_queue(ctx-src_queue,
+ ctx-vq_src);
+ if (q-type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
+ INIT_LIST_HEAD(ctx-dst_queue);
+ if (q-type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
+ INIT_LIST_HEAD(ctx-src_queue);
+ spin_unlock_irqrestore(dev-irqlock, flags);
+ return 0;
+}
This function is called by __vb2_queue_cancel().and
__vb2_queue_cancel()
can be
called by vb2_queue_release() or vb2_streamoff().
But, in this s5p_mfc_stop_streaming(),s5p_mfc_error_cleanup_queue() for
src/dst
is runned regardless of q-type. Is that right ?
and in case of streamoff, queued bufs should be removed, then qbuf is
needed
before streamon again, so ctx-dst_queue_cnt = 0; ctx-src_queue_cnt =
0;
is required
what do you think about this ?
It has to be changed to support pause and dynamic resolution change.
Best wishes,
--
Kamil Debski
Linux Platform Group
Samsung Poland RD Center
--
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 0/1] v4l: videobuf2: Add DMA pool allocator
Hi, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Marek Szyprowski Sent: Tuesday, January 18, 2011 12:48 AM To: 'Jeongtae Park'; linux-media@vger.kernel.org; linux-samsung- s...@vger.kernel.org Cc: k.deb...@samsung.com; jaeryul...@samsung.com; jonghun@samsung.com; kgene@samsung.com Subject: RE: [PATCH 0/1] v4l: videobuf2: Add DMA pool allocator Hello, On Thursday, December 30, 2010 5:55 AM Jeongtae Park wrote: The DMA pool allocator allocates a memory using dma_alloc_coherent(), creates a pool using generic allocator in the initialization. For every allocation requests, the allocator returns a part of its memory pool using generic allocator instead of new memory allocation. This allocator used for devices have below limitations. - the start address should be aligned - the range of memory access limited to the offset from the start address (= the allocation address should be existed in a constant offset from the start address) - the allocation address should be aligned I would be grateful for your comments. This patch series contains: [PATCH 1/1] v4l: videobuf2: Add DMA pool allocator Best regards, Jeongtae Park Patch summary: Jeongtae Park (1): v4l: videobuf2: Add DMA pool allocator drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/videobuf2-dma-pool.c | 310 ++ include/media/videobuf2-dma-pool.h | 37 4 files changed, 355 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/videobuf2-dma-pool.c create mode 100644 include/media/videobuf2-dma-pool.h The code looks nice but I have one suggestion. This dma-pool memory allocator make sense only for a s5p-mfc driver. All other drivers can use dma-contig vb2 allocator directly. For this reason I suggest to move this allocator directly to drivers/media/video/s5p-mfc/ directory. Is it not possible that there is the device with above limitations or constraints? If it's possible, the dma-pool allocator can be useful, but currently this allocator is useful only for a s5p-mfc. But, all other allocators of vb2 framework are drivers/media/video/ directory. I'm not sure which position is right for dma-pool allocator. Thanks for your comment. Best regards -- Marek Szyprowski Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Best regards -- 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
camera on Freescale i.MX51
Hi, I'm have trouble receiving a video stream on the Freescale i.MX51 processor. I've tried everything I could think, so I'm trying my luck here. I'm using a 2.6.31 kernel with some modifications: the camera capture driver [1] and the IPU (Image Processing Unit) driver [2] from the Freescale BSP 2010.11. I'm at a point where I can open the /dev/video0 device and can (at least try to) read frames, but it fails at dequeueing the video buffers (VIDIOC_DQBUF) with the message: 3ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0 Unable to dequeue buffer (62). - I've double-checked the IPU registers and they seem properly configured, but I don't get any interrupt (at end-of-frame). - The relevant IOMUX pins are also configured. - the video signal appears at the i.MX pins (so it gets there) - I've also tried activating the internal picture generator, but still nothing happens. Is there anything I overlooked? Is there a way to find out where the problem is? Any hints will be greatly appreciated. Thanks! Claudiu [1] http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=blob;f=drivers/media/video/mxc/capture/mxc_v4l2_capture.c;h=8133d202304eea22e94bbd8eaaa215002b2dc675;hb=0fae922f451a5bde63595a2e0c2cd7079f083440 [2] http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=tree;f=drivers/mxc/ipu3;h=288c21f88aa650d16d843dccec2b04ba9f1462f7;hb=0fae922f451a5bde63595a2e0c2cd7079f083440 -- 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 v16 0/3] davinci vpbe: dm6446 v4l2 driver
version16 : addressed Sergei's comments on: 1. Minor code change. 2. Interchanged the sequence of patches. Signed-off-by: Manjunath Hadli manjunath.hadli@xx Acked-by: Muralidharan Karicheri m-karicheri2@xx Acked-by: Hans Verkuil hverkuil@x Manjunath Hadli (3): davinci vpbe: changes to common files davinci vpbe: platform specific additions davinci vpbe: board specific additions arch/arm/mach-davinci/board-dm644x-evm.c | 84 ++--- arch/arm/mach-davinci/common.c|4 +- arch/arm/mach-davinci/devices.c | 10 +- arch/arm/mach-davinci/dm644x.c| 169 +++-- arch/arm/mach-davinci/include/mach/dm644x.h |5 + arch/arm/mach-davinci/include/mach/hardware.h |5 + 6 files changed, 244 insertions(+), 33 deletions(-) -- 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 v16 1/3] davinci vpbe: changes to common files
Implemented a common and single mapping for DAVINCI_SYSTEM_MODULE_BASE
to be used by all davinci platforms.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
arch/arm/mach-davinci/common.c|4 +++-
arch/arm/mach-davinci/devices.c | 10 --
arch/arm/mach-davinci/include/mach/hardware.h |5 +
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/common.c b/arch/arm/mach-davinci/common.c
index 1d25573..949e615 100644
--- a/arch/arm/mach-davinci/common.c
+++ b/arch/arm/mach-davinci/common.c
@@ -111,7 +111,9 @@ void __init davinci_common_init(struct davinci_soc_info
*soc_info)
if (ret != 0)
goto err;
}
-
+ davinci_sysmodbase = ioremap_nocache(DAVINCI_SYSTEM_MODULE_BASE, 0x800);
+ if (!davinci_sysmodbase)
+ goto err;
return;
err:
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 22ebc64..2bff2d6 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -33,6 +33,8 @@
#define DM365_MMCSD0_BASE 0x01D11000
#define DM365_MMCSD1_BASE 0x01D0
+void __iomem *davinci_sysmodbase;
+
static struct resource i2c_resources[] = {
{
.start = DAVINCI_I2C_BASE,
@@ -209,9 +211,7 @@ void __init davinci_setup_mmc(int module, struct
davinci_mmc_config *config)
davinci_cfg_reg(DM355_SD1_DATA2);
davinci_cfg_reg(DM355_SD1_DATA3);
} else if (cpu_is_davinci_dm365()) {
- void __iomem *pupdctl1 =
- IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE + 0x7c);
-
+ void __iomem *pupdctl1 = DAVINCI_SYSMODULE_VIRT(0x7c);
/* Configure pull down control */
__raw_writel((__raw_readl(pupdctl1) ~0xfc0),
pupdctl1);
@@ -243,9 +243,7 @@ void __init davinci_setup_mmc(int module, struct
davinci_mmc_config *config)
mmcsd0_resources[2].start = IRQ_DM365_SDIOINT0;
} else if (cpu_is_davinci_dm644x()) {
/* REVISIT: should this be in board-init code? */
- void __iomem *base =
- IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
-
+ void __iomem *base = DAVINCI_SYSMODULE_VIRT(0);
/* Power-on 3.3V IO cells */
__raw_writel(0, base + DM64XX_VDD3P3V_PWDN);
/*Set up the pull regiter for MMC */
diff --git a/arch/arm/mach-davinci/include/mach/hardware.h
b/arch/arm/mach-davinci/include/mach/hardware.h
index c45ba1f..5a105c4 100644
--- a/arch/arm/mach-davinci/include/mach/hardware.h
+++ b/arch/arm/mach-davinci/include/mach/hardware.h
@@ -24,6 +24,11 @@
/* System control register offsets */
#define DM64XX_VDD3P3V_PWDN0x48
+#ifndef __ASSEMBLER__
+ extern void __iomem *davinci_sysmodbase;
+ #define DAVINCI_SYSMODULE_VIRT(x) (davinci_sysmodbase+(x))
+#endif
+
/*
* I/O mapping
*/
--
1.6.2.4
--
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 v16 2/3] davinci vpbe: platform specific additions
This patch implements the overall device creation for the Video
display driver, initializes the platform variables and implements
platform functions including setting video clocks.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
arch/arm/mach-davinci/dm644x.c | 169 +--
arch/arm/mach-davinci/include/mach/dm644x.h |5 +
2 files changed, 163 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 9a2376b..45a89a8 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -586,12 +586,14 @@ static struct platform_device dm644x_asp_device = {
.resource = dm644x_asp_resources,
};
+#define DM644X_VPSS_REG_BASE 0x01c73400
+
static struct resource dm644x_vpss_resources[] = {
{
/* VPSS Base address */
.name = vpss,
- .start = 0x01c73400,
- .end= 0x01c73400 + 0xff,
+ .start = DM644X_VPSS_REG_BASE,
+ .end= DM644X_VPSS_REG_BASE + 0xff,
.flags = IORESOURCE_MEM,
},
};
@@ -618,6 +620,7 @@ static struct resource vpfe_resources[] = {
};
static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+
static struct resource dm644x_ccdc_resource[] = {
/* CCDC Base address */
{
@@ -654,6 +657,137 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg)
vpfe_capture_dev.dev.platform_data = cfg;
}
+#define DM644X_OSD_REG_BASE0x01C72600
+
+static struct resource dm644x_osd_resources[] = {
+ {
+ .start = DM644X_OSD_REG_BASE,
+ .end= DM644X_OSD_REG_BASE + 0x1ff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64 dm644x_osd_dma_mask = DMA_BIT_MASK(32);
+
+static struct osd_platform_data osd_data = {
+ .vpbe_type = DM644X_VPBE,
+};
+
+static struct platform_device dm644x_osd_dev = {
+ .name = VPBE_OSD_SUBDEV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_osd_resources),
+ .resource = dm644x_osd_resources,
+ .dev = {
+ .dma_mask = dm644x_osd_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = osd_data,
+ },
+};
+
+#define DM644X_VENC_REG_BASE 0x01C72400
+
+static struct resource dm644x_venc_resources[] = {
+ /* venc registers io space */
+ {
+ .start = DM644X_VENC_REG_BASE,
+ .end= DM644X_VENC_REG_BASE + 0x17f,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64 dm644x_venc_dma_mask = DMA_BIT_MASK(32);
+
+static void __iomem *vpss_clkctl_reg;
+
+static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type, __u64 mode)
+{
+ int ret = 0;
+
+ switch (type) {
+ case VPBE_ENC_STD:
+ writel(0x18, vpss_clkctl_reg);
+ break;
+ case VPBE_ENC_DV_PRESET:
+ switch ((unsigned int)mode) {
+ case V4L2_DV_480P59_94:
+ case V4L2_DV_576P50:
+ writel(0x19, vpss_clkctl_reg);
+ break;
+ case V4L2_DV_720P60:
+ case V4L2_DV_1080I60:
+ case V4L2_DV_1080P30:
+ /*
+* For HD, use external clock source since
+* HD requires higher clock rate
+*/
+ writel(0xa, vpss_clkctl_reg);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ break;
+ default:
+ ret = -EINVAL;
+ }
+ return ret;
+}
+
+static u64 vpbe_display_dma_mask = DMA_BIT_MASK(32);
+
+static struct resource dm644x_v4l2_disp_resources[] = {
+ {
+ .start = IRQ_VENCINT,
+ .end= IRQ_VENCINT,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device vpbe_v4l2_display = {
+ .name = vpbe-v4l2,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_v4l2_disp_resources),
+ .resource = dm644x_v4l2_disp_resources,
+ .dev = {
+ .dma_mask = vpbe_display_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
+struct venc_platform_data dm644x_venc_pdata = {
+ .venc_type = DM644X_VPBE,
+ .setup_clock= dm644x_venc_setup_clock,
+};
+
+static struct platform_device dm644x_venc_dev = {
+ .name = VPBE_VENC_SUBDEV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_venc_resources),
[PATCH v16 3/3] davinci vpbe: board specific additions
This patch implements tables for display timings,outputs and
other board related functionalities.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
arch/arm/mach-davinci/board-dm644x-evm.c | 84 -
1 files changed, 69 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 0ca90b8..95ea13d 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -176,18 +176,6 @@ static struct platform_device davinci_evm_nandflash_device
= {
.resource = davinci_evm_nandflash_resource,
};
-static u64 davinci_fb_dma_mask = DMA_BIT_MASK(32);
-
-static struct platform_device davinci_fb_device = {
- .name = davincifb,
- .id = -1,
- .dev = {
- .dma_mask = davinci_fb_dma_mask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- },
- .num_resources = 0,
-};
-
static struct tvp514x_platform_data tvp5146_pdata = {
.clk_polarity = 0,
.hs_polarity = 1,
@@ -337,7 +325,6 @@ static struct pcf857x_platform_data pcf_data_u2 = {
.teardown = evm_led_teardown,
};
-
/* U18 - A/V clock generator and user switch */
static int sw_gpio;
@@ -404,7 +391,6 @@ static struct pcf857x_platform_data pcf_data_u18 = {
.teardown = evm_u18_teardown,
};
-
/* U35 - various I/O signals used to manage USB, CF, ATA, etc */
static int
@@ -616,8 +602,73 @@ static void __init evm_init_i2c(void)
i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
}
+#define VENC_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/* venc standards timings */
+static struct vpbe_enc_mode_info vbpe_enc_std_timings[] = {
+ {ntsc, VPBE_ENC_STD, {V4L2_STD_525_60}, 1, 720, 480,
+ {11, 10}, {3, 1001}, 0x79, 0, 0x10, 0, 0, 0, 0},
+ {pal, VPBE_ENC_STD, {V4L2_STD_625_50}, 1, 720, 576,
+ {54, 59}, {25, 1}, 0x7E, 0, 0x16, 0, 0, 0, 0},
+};
+
+/* venc dv preset timings */
+static struct vpbe_enc_mode_info vbpe_enc_preset_timings[] = {
+ {480p59_94, VPBE_ENC_DV_PRESET, {V4L2_DV_480P59_94}, 0, 720, 480,
+ {1, 1}, {5994, 100}, 0x80, 0, 0x20, 0, 0, 0, 0},
+ {576p50, VPBE_ENC_DV_PRESET, {V4L2_DV_576P50}, 0, 720, 576,
+ {1, 1}, {50, 1}, 0x7E, 0, 0x30, 0, 0, 0, 0},
+};
+
+/*
+ * The outputs available from VPBE + encoders. Keep the order same
+ * as that of encoders. First that from venc followed by that from
+ * encoders. Index in the output refers to index on a particular encoder.
+ * Driver uses this index to pass it to encoder when it supports more than
+ * one output. Application uses index of the array to set an output.
+ */
+static struct vpbe_output dm644x_vpbe_outputs[] = {
+ {
+ .output = {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_OUTPUT_TYPE_ANALOG,
+ .std = VENC_STD_ALL,
+ .capabilities = V4L2_OUT_CAP_STD,
+ },
+ .subdev_name = VPBE_VENC_SUBDEV_NAME,
+ .default_mode = ntsc,
+ .num_modes = ARRAY_SIZE(vbpe_enc_std_timings),
+ .modes = vbpe_enc_std_timings,
+ },
+ {
+ .output = {
+ .index = 1,
+ .name = Component,
+ .type = V4L2_OUTPUT_TYPE_ANALOG,
+ .capabilities = V4L2_OUT_CAP_PRESETS,
+ },
+ .subdev_name = VPBE_VENC_SUBDEV_NAME,
+ .default_mode = 480p59_94,
+ .num_modes = ARRAY_SIZE(vbpe_enc_preset_timings),
+ .modes = vbpe_enc_preset_timings,
+ },
+};
+
+static struct vpbe_display_config vpbe_display_cfg = {
+ .module_name = dm644x-vpbe-display,
+ .i2c_adapter_id = 1,
+ .osd = {
+ .module_name = VPBE_OSD_SUBDEV_NAME,
+ },
+ .venc = {
+ .module_name = VPBE_VENC_SUBDEV_NAME,
+ },
+ .num_outputs = ARRAY_SIZE(dm644x_vpbe_outputs),
+ .outputs = dm644x_vpbe_outputs,
+};
+
static struct platform_device *davinci_evm_devices[] __initdata = {
- davinci_fb_device,
rtc_dev,
};
@@ -630,6 +681,9 @@ davinci_evm_map_io(void)
{
/* setup input configuration for VPFE input devices */
dm644x_set_vpfe_config(vpfe_cfg);
+
+ /* setup configuration for vpbe devices */
+ dm644x_set_vpbe_display_config(vpbe_display_cfg);
dm644x_init();
}
--
1.6.2.4
--
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
[libdvben50221] [PATCH] Assign same resource_id in open_session_response when resource non-existent
Attached a patch for a bug in the lookup_callback function, were in case of a non-existent resource, the connected_resource_id is not initialized and then used in the open_session_response call of the session layer. Tomer diff -r d3509d6e9499 lib/libdvben50221/en50221_stdcam_llci.c --- a/lib/libdvben50221/en50221_stdcam_llci.c Sat Aug 08 19:17:21 2009 +0200 +++ b/lib/libdvben50221/en50221_stdcam_llci.c Tue Jan 18 14:51:34 2011 +0200 @@ -351,6 +351,10 @@ } } + /* In case the reousrce does not exist, return the same id in the response. + See 7.2.6.2 */ + *connected_resource_id = requested_resource_id; + return -1; }
WL1273 FM Radio driver...
Hello I have been trying to get the WL1273 FM radio driver into the kernel for some time. It has been kind of difficult, one of the reasons is that I didn't realize I should have tried to involve all relevant maintainers to the discussion form the beginning (AsoC, Media and MFD). At Mark's suggestion I'm trying to reopen the discussion now. The driver consists of an MFD core and two child drivers (the audio codec and the V4L2 driver). And the question is mainly about the role of the MFD driver: the original design had the IO functions in the core. Currently the core is practically empty mainly because Mauro very strongly wanted to have “everything” in the V4L2 driver. I liked the original design because it didn't have the bug that the current MFD has: the codec can be initialized before the V4L2 part sets the IO function pointers. Having in principle equally capable interface drivers is symmetrical and esthetically pleasing:-) Also somebody could easily leave out the existing interfaces and create a completely new one based for example to sysfs or something... Having the IO in the core would also conveniently hide the physical communication layer and make it easy to change I2C to UART, which is also supported by the chip. Thanks, Matti -- 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: PROBLEM: kernel BUG at drivers/media/video/em28xx/em28xx-video.c:891
Hello Rune I'm trying to learn more about the linux kernel so I figured helping with bugs is a good way to get started. On 01/18/2011 02:20 AM, Rune Saetre wrote: Hi The crash is not as consistent as I first believed. I have managed to stop and start capturing several (but not many) times without the driver crashing now. To me it seems that the resource locking (functions res_get, res_check, res_locked and res_free) is subject to race condition. I looked at older versions of the code and found that there used to be locks around some of these pieces. It was removed in commit: 0499a5aa777f8e56e46df362f0bb9d9d116186f9 - V4L/DVB: em28xx: remove BKL Other V4L drivers use pretty much the same code (res_get, res_free, etc.) for resource locking but still have the mutex_lock/unlock around it. Does anyone know why this was removed? Thanks Patrik Jakobsson The trace logs also differ slightly. Here is the last one: Jan 18 02:12:08 mate kernel: [ 117.219326] [ cut here ] Jan 18 02:12:08 mate kernel: [ 117.219412] kernel BUG at drivers/media/video/em28xx/em28xx-video.c:891! Jan 18 02:12:08 mate kernel: [ 117.219507] invalid opcode: [#1] PREEMPT SMP Jan 18 02:12:08 mate kernel: [ 117.219597] last sysfs file: /sys/devices/virtual/block/dm-8/stat Jan 18 02:12:08 mate kernel: [ 117.219681] CPU 1 Jan 18 02:12:08 mate kernel: [ 117.219714] Modules linked in: acpi_cpufreq mperf cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_conservative ppdev lp nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs binfmt_misc fuse dummy bridge stp ext2 mbcache coretemp kvm_intel kvm loop firewire_sbp2 tuner snd_hda_codec_realtek arc4 snd_hda_intel snd_usb_audio snd_hda_codec ecb snd_seq_dummy snd_pcm_oss snd_mixer_oss saa7115 snd_pcm ir_lirc_codec lirc_dev ir_sony_decoder snd_hwdep snd_usbmidi_lib em28xx ir_jvc_decoder ir_rc6_decoder snd_seq_oss snd_seq_midi snd_rawmidi r8169 ir_rc5_decoder mii ir_nec_decoder snd_seq_midi_event i915 v4l2_common iwlagn iwlcore snd_seq ir_core drm_kms_helper drm videobuf_vmalloc snd_timer snd_seq_device videobuf_core pcmcia joydev mac80211 uvcvideo videodev v4l1_compat v4l2_compat_ioctl32 tveeprom cfg80211 rfkill i2c_i801 i2c_algo_bit tpm_tis tpm yenta_socket snd intel_agp shpchp pci_hotplug video output pcmcia_rsrc wmi pcmcia_core soundcore snd_page_alloc parport_pc parport i2c_cor Jan 18 02:12:08 mate kernel: irda tpm_bios intel_gtt pcspkr crc_ccitt psmouse evdev serio_raw container processor battery ac button reiserfs dm_mod raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 raid0 multipath linear md_mod ide_cd_mod cdrom sd_mod ata_generic pata_acpi ata_piix crc_t10dif ide_pci_generic ahci libahci sdhci_pci firewire_ohci sdhci libata scsi_mod piix ide_core firewire_core mmc_core uhci_hcd tg3 thermal crc_itu_t thermal_sys ehci_hcd [last unloaded: scsi_wait_scan] Jan 18 02:12:08 mate kernel: [ 117.220091] Jan 18 02:12:08 mate kernel: [ 117.220091] Pid: 3154, comm: camera_factory_ Not tainted 2.6.37-rst #1 Victoria/TravelMate 6292 Jan 18 02:12:08 mate kernel: [ 117.220091] RIP: 0010:[a05a37f4] [a05a37f4] res_free+0x14/0x49 [em28xx] Jan 18 02:12:08 mate kernel: [ 117.220091] RSP: 0018:8800794a1c48 EFLAGS: 00010297 Jan 18 02:12:08 mate kernel: [ 117.220091] RAX: 0001 RBX: 88007b94dc00 RCX: Jan 18 02:12:08 mate kernel: [ 117.220091] RDX: RSI: 8800378e7000 RDI: 88007b94dc00 Jan 18 02:12:09 mate kernel: [ 117.220091] RBP: 8800378e7000 R08: 0001 R09: 0c52 Jan 18 02:12:09 mate kernel: [ 117.220091] R10: R11: 0246 R12: Jan 18 02:12:09 mate kernel: [ 117.220091] R13: a05ab920 R14: 88006dd123c0 R15: 88007b94dc00 Jan 18 02:12:09 mate kernel: [ 117.220091] FS: 7f37105bb820() GS:88007f50() knlGS: Jan 18 02:12:09 mate kernel: [ 117.220091] CS: 0010 DS: ES: CR0: 80050033 Jan 18 02:12:09 mate kernel: [ 117.220091] CR2: 0378b248 CR3: 7a079000 CR4: 06e0 Jan 18 02:12:09 mate kernel: [ 117.220091] DR0: DR1: DR2: Jan 18 02:12:09 mate kernel: [ 117.220091] DR3: DR6: 0ff0 DR7: 0400 Jan 18 02:12:09 mate kernel: [ 117.220091] Process camera_factory_ (pid: 3154, threadinfo 8800794a, task 880071f6d820) Jan 18 02:12:09 mate kernel: [ 117.220091] Stack: Jan 18 02:12:09 mate kernel: [ 117.220091] 8800378e7000 a05a46b9 88007a2fd040 81042cf3 Jan 18 02:12:09 mate kernel: [ 117.220091] 0001 0001 8103dadb 0001 Jan 18 02:12:09 mate kernel: [ 117.220091] 88007ba3e400 a03302ff 000135c0 000135c0 Jan 18 02:12:09 mate
link error w/ media-0006-sensors
Hi Laurent Sakari, On Laurent's media-0006-sensors branch, when compiling with CONFIG_VIDEO_OMAP3=m, I got the following linking error: ERROR: omap_pm_set_min_bus_tput [drivers/media/video/isp/omap3-isp.ko] undefined! I can get rid of the error with the patch below. But as always, I wonder: Why didn't anybody else come across this error? Are you all compiling with VIDEO_OMAP3=y? Is there a config file somewhere I can see where someone is using that? And would anything be wrong with the patch below? -Michael diff --git a/arch/arm/plat-omap/omap-pm-noop.c b/arch/arm/plat-omap/omap-pm-noop.c index e129ce8..9e0bcb6 100644 --- a/arch/arm/plat-omap/omap-pm-noop.c +++ b/arch/arm/plat-omap/omap-pm-noop.c @@ -88,6 +88,7 @@ int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r) return 0; } +EXPORT_SYMBOL_GPL(omap_pm_set_min_bus_tput); int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct device *dev, long t) MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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: PROBLEM: kernel BUG at drivers/media/video/em28xx/em28xx-video.c:891
On Tuesday, January 18, 2011 17:14:03 Patrik Jakobsson wrote: Hello Rune I'm trying to learn more about the linux kernel so I figured helping with bugs is a good way to get started. On 01/18/2011 02:20 AM, Rune Saetre wrote: Hi The crash is not as consistent as I first believed. I have managed to stop and start capturing several (but not many) times without the driver crashing now. To me it seems that the resource locking (functions res_get, res_check, res_locked and res_free) is subject to race condition. I looked at older versions of the code and found that there used to be locks around some of these pieces. It was removed in commit: 0499a5aa777f8e56e46df362f0bb9d9d116186f9 - V4L/DVB: em28xx: remove BKL Other V4L drivers use pretty much the same code (res_get, res_free, etc.) for resource locking but still have the mutex_lock/unlock around it. Does anyone know why this was removed? Because now the video4linux core does the locking. Anyway, I'm pretty sure this is the bug that was fixed here: http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09413.html This fix will be in 2.6.38. The change in the locking mechanism had nothing to do this particular bug. It was just incorrect administration of resources. Regards, Hans Thanks Patrik Jakobsson The trace logs also differ slightly. Here is the last one: Jan 18 02:12:08 mate kernel: [ 117.219326] [ cut here ] Jan 18 02:12:08 mate kernel: [ 117.219412] kernel BUG at drivers/media/video/em28xx/em28xx-video.c:891! Jan 18 02:12:08 mate kernel: [ 117.219507] invalid opcode: [#1] PREEMPT SMP Jan 18 02:12:08 mate kernel: [ 117.219597] last sysfs file: /sys/devices/virtual/block/dm-8/stat Jan 18 02:12:08 mate kernel: [ 117.219681] CPU 1 Jan 18 02:12:08 mate kernel: [ 117.219714] Modules linked in: acpi_cpufreq mperf cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_conservative ppdev lp nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs binfmt_misc fuse dummy bridge stp ext2 mbcache coretemp kvm_intel kvm loop firewire_sbp2 tuner snd_hda_codec_realtek arc4 snd_hda_intel snd_usb_audio snd_hda_codec ecb snd_seq_dummy snd_pcm_oss snd_mixer_oss saa7115 snd_pcm ir_lirc_codec lirc_dev ir_sony_decoder snd_hwdep snd_usbmidi_lib em28xx ir_jvc_decoder ir_rc6_decoder snd_seq_oss snd_seq_midi snd_rawmidi r8169 ir_rc5_decoder mii ir_nec_decoder snd_seq_midi_event i915 v4l2_common iwlagn iwlcore snd_seq ir_core drm_kms_helper drm videobuf_vmalloc snd_timer snd_seq_device videobuf_core pcmcia joydev mac80211 uvcvideo videodev v4l1_compat v4l2_compat_ioctl32 tveeprom cfg80211 rfkill i2c_i801 i2c_algo_bit tpm_tis tpm yenta_socket snd intel_agp shpchp pci_hotplug video output pcmcia_rsrc wmi pcmcia_core soundcore snd_page_alloc parport_pc parport i2c_cor Jan 18 02:12:08 mate kernel: irda tpm_bios intel_gtt pcspkr crc_ccitt psmouse evdev serio_raw container processor battery ac button reiserfs dm_mod raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 raid0 multipath linear md_mod ide_cd_mod cdrom sd_mod ata_generic pata_acpi ata_piix crc_t10dif ide_pci_generic ahci libahci sdhci_pci firewire_ohci sdhci libata scsi_mod piix ide_core firewire_core mmc_core uhci_hcd tg3 thermal crc_itu_t thermal_sys ehci_hcd [last unloaded: scsi_wait_scan] Jan 18 02:12:08 mate kernel: [ 117.220091] Jan 18 02:12:08 mate kernel: [ 117.220091] Pid: 3154, comm: camera_factory_ Not tainted 2.6.37-rst #1 Victoria/TravelMate 6292 Jan 18 02:12:08 mate kernel: [ 117.220091] RIP: 0010:[a05a37f4] [a05a37f4] res_free+0x14/0x49 [em28xx] Jan 18 02:12:08 mate kernel: [ 117.220091] RSP: 0018:8800794a1c48 EFLAGS: 00010297 Jan 18 02:12:08 mate kernel: [ 117.220091] RAX: 0001 RBX: 88007b94dc00 RCX: Jan 18 02:12:08 mate kernel: [ 117.220091] RDX: RSI: 8800378e7000 RDI: 88007b94dc00 Jan 18 02:12:09 mate kernel: [ 117.220091] RBP: 8800378e7000 R08: 0001 R09: 0c52 Jan 18 02:12:09 mate kernel: [ 117.220091] R10: R11: 0246 R12: Jan 18 02:12:09 mate kernel: [ 117.220091] R13: a05ab920 R14: 88006dd123c0 R15: 88007b94dc00 Jan 18 02:12:09 mate kernel: [ 117.220091] FS: 7f37105bb820() GS:88007f50() knlGS: Jan 18 02:12:09 mate kernel: [ 117.220091] CS: 0010 DS: ES: CR0: 80050033 Jan 18 02:12:09 mate kernel: [ 117.220091] CR2: 0378b248 CR3: 7a079000 CR4: 06e0 Jan 18 02:12:09 mate kernel: [ 117.220091] DR0: DR1: DR2: Jan 18 02:12:09 mate kernel: [ 117.220091] DR3: DR6: 0ff0 DR7:
RE: [PATCH v16 1/3] davinci vpbe: changes to common files
Hi Manju,
You have got a wrong address for linux-arm-kernel ML.
The right address is: linux-arm-ker...@lists.infradead.org
Also, I think you need to subscribe to this list for your
messages to get posted automatically. Subscription information
is available here: http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
You can check that your patches are actually reaching ARM linux
mailing list by checking the archives here: http://marc.info/?l=linux-arm-kernel
On Tue, Jan 18, 2011 at 19:09:07, Hadli, Manjunath wrote:
Implemented a common and single mapping for DAVINCI_SYSTEM_MODULE_BASE
to be used by all davinci platforms.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
arch/arm/mach-davinci/common.c|4 +++-
arch/arm/mach-davinci/devices.c | 10 --
arch/arm/mach-davinci/include/mach/hardware.h |5 +
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/common.c b/arch/arm/mach-davinci/common.c
index 1d25573..949e615 100644
--- a/arch/arm/mach-davinci/common.c
+++ b/arch/arm/mach-davinci/common.c
@@ -111,7 +111,9 @@ void __init davinci_common_init(struct davinci_soc_info
*soc_info)
if (ret != 0)
goto err;
}
-
+ davinci_sysmodbase = ioremap_nocache(DAVINCI_SYSTEM_MODULE_BASE, 0x800);
+ if (!davinci_sysmodbase)
+ goto err;
This is actually not the right place to do this. davinci_common_init()
is called for all 7 supported SoCs. This system module base address
definitely not valid on the two DA8x SoCs. I suspect it is not valid on
TNETV as well. That makes this call unnecessary on 3 of the 7 supported
SoCs. I think the original approach of mapping it for each SoC that needed
it was fine.
return;
err:
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 22ebc64..2bff2d6 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -33,6 +33,8 @@
#define DM365_MMCSD0_BASE 0x01D11000
#define DM365_MMCSD1_BASE 0x01D0
+void __iomem *davinci_sysmodbase;
+
static struct resource i2c_resources[] = {
{
.start = DAVINCI_I2C_BASE,
@@ -209,9 +211,7 @@ void __init davinci_setup_mmc(int module, struct
davinci_mmc_config *config)
davinci_cfg_reg(DM355_SD1_DATA2);
davinci_cfg_reg(DM355_SD1_DATA3);
} else if (cpu_is_davinci_dm365()) {
- void __iomem *pupdctl1 =
- IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE + 0x7c);
-
+ void __iomem *pupdctl1 = DAVINCI_SYSMODULE_VIRT(0x7c);
/* Configure pull down control */
__raw_writel((__raw_readl(pupdctl1) ~0xfc0),
pupdctl1);
@@ -243,9 +243,7 @@ void __init davinci_setup_mmc(int module, struct
davinci_mmc_config *config)
mmcsd0_resources[2].start = IRQ_DM365_SDIOINT0;
} else if (cpu_is_davinci_dm644x()) {
/* REVISIT: should this be in board-init code? */
- void __iomem *base =
- IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
-
+ void __iomem *base = DAVINCI_SYSMODULE_VIRT(0);
Please use DAVINCI_SYSMODULE_VIRT(DM64XX_VDD3P3V_PWDN) instead.
/* Power-on 3.3V IO cells */
__raw_writel(0, base + DM64XX_VDD3P3V_PWDN);
/*Set up the pull regiter for MMC */
diff --git a/arch/arm/mach-davinci/include/mach/hardware.h
b/arch/arm/mach-davinci/include/mach/hardware.h
index c45ba1f..5a105c4 100644
--- a/arch/arm/mach-davinci/include/mach/hardware.h
+++ b/arch/arm/mach-davinci/include/mach/hardware.h
@@ -24,6 +24,11 @@
/* System control register offsets */
#define DM64XX_VDD3P3V_PWDN 0x48
+#ifndef __ASSEMBLER__
+ extern void __iomem *davinci_sysmodbase;
+ #define DAVINCI_SYSMODULE_VIRT(x) (davinci_sysmodbase+(x))
Indenting the #defines is not required.
Also, this will need to be placed in individual soc.h file. The currently
defined DAVINCI_SYSTEM_MODULE_BASE and DM64XX_VDD3P3V_PWDN also violate the
guidance provided in comments just before those defines. They should be
moved to soc.h files too.
Thanks,
Sekhar
--
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] [media] v4l: soc-camera: add enum-frame-size ioctl
On Mon, 17 Jan 2011, Qing Xu wrote:
add vidioc_enum_framesizes implementation, follow default_g_parm()
and g_mbus_fmt() method
Signed-off-by: Qing Xu qi...@marvell.com
---
drivers/media/video/soc_camera.c | 42
++
include/media/soc_camera.h |1 +
include/media/v4l2-subdev.h |2 +
3 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c
index 052bd6d..35260a5 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -145,6 +145,18 @@ static int soc_camera_s_std(struct file *file, void
*priv, v4l2_std_id *a)
return v4l2_subdev_call(sd, core, s_std, *a);
}
+static int soc_camera_enum_fsizes(struct file *file, void *fh,
+ struct v4l2_frmsizeenum *fsize)
+{
+ struct soc_camera_device *icd = file-private_data;
+ struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+
+ if (ici-ops-enum_fsizes)
+ return ici-ops-enum_fsizes(icd, fsize);
+
+ return -ENOIOCTLCMD;
Do you need this? We don't do this with other similar operations: if none
is provided by the user, we supply our own default, so, don't think we
need to check for NULL here.
+}
+
static int soc_camera_reqbufs(struct file *file, void *priv,
struct v4l2_requestbuffers *p)
{
@@ -1160,6 +1172,33 @@ static int default_s_parm(struct soc_camera_device
*icd,
return v4l2_subdev_call(sd, video, s_parm, parm);
}
+static int default_enum_fsizes(struct soc_camera_device *icd,
+ struct v4l2_frmsizeenum *fsize)
+{
+ int ret;
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ struct v4l2_mbus_framefmt mf;
+ const struct soc_camera_format_xlate *xlate;
+ __u32 pixfmt = fsize-pixel_format;
+
+ xlate = soc_camera_xlate_by_fourcc(icd, pixfmt);
+ if (!xlate) {
+ return -EINVAL;
+ }
Superfluous braces.
+
+ mf.code = xlate-code;
+
+ ret = v4l2_subdev_call(sd, video, enum_mbus_fsizes, mf);
+ if (ret 0)
+ return ret;
+
+ fsize-discrete.height = mf.height;
+ fsize-discrete.width = mf.width;
+ fsize-type = V4L2_FRMSIZE_TYPE_DISCRETE;
Hmm, no, that's not quite what I meant. I meant something like this:
+ struct v4l2_frmsizeenum fsize_mbus = *fsize;
...
+ fsize_mbus.pixel_format = xlate-code;
+ ret = v4l2_subdev_call(sd, video, enum_mbus_fsizes, fsize_mbus);
Of course, you'll have to change your prototypes in the header
respectively. With your solution you hard-code only one discrete size,
which doesn't seem like a good idea to me.
Thanks
Guennadi
+
+ return 0;
+}
+
static void soc_camera_device_init(struct device *dev, void *pdata)
{
dev-platform_data = pdata;
@@ -1195,6 +1234,8 @@ int soc_camera_host_register(struct soc_camera_host
*ici)
ici-ops-set_parm = default_s_parm;
if (!ici-ops-get_parm)
ici-ops-get_parm = default_g_parm;
+ if (!ici-ops-enum_fsizes)
+ ici-ops-enum_fsizes = default_enum_fsizes;
mutex_lock(list_lock);
list_for_each_entry(ix, hosts, list) {
@@ -1302,6 +1343,7 @@ static const struct v4l2_ioctl_ops soc_camera_ioctl_ops
= {
.vidioc_g_input = soc_camera_g_input,
.vidioc_s_input = soc_camera_s_input,
.vidioc_s_std= soc_camera_s_std,
+ .vidioc_enum_framesizes = soc_camera_enum_fsizes,
.vidioc_reqbufs = soc_camera_reqbufs,
.vidioc_try_fmt_vid_cap = soc_camera_try_fmt_vid_cap,
.vidioc_querybuf = soc_camera_querybuf,
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 86e3631..6e4800c 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -85,6 +85,7 @@ struct soc_camera_host_ops {
int (*set_ctrl)(struct soc_camera_device *, struct v4l2_control *);
int (*get_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
int (*set_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
+ int (*enum_fsizes)(struct soc_camera_device *, struct v4l2_frmsizeenum
*);
unsigned int (*poll)(struct file *, poll_table *);
const struct v4l2_queryctrl *controls;
int num_controls;
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index b0316a7..d4e0d80 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -275,6 +275,8 @@ struct v4l2_subdev_video_ops {
struct v4l2_dv_timings *timings);
int (*enum_mbus_fmt)(struct v4l2_subdev *sd, unsigned int index,
enum v4l2_mbus_pixelcode *code);
+ int (*enum_mbus_fsizes)(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *fmt);
RE: soc-camera jpeg support?
Thanks for the code! With it at hand it is going to be easier to
understand and evaluate changes, that you propose to the generic modules.
On Mon, 17 Jan 2011, Qing Xu wrote:
Hi, Guennadi,
Oh, yes, I agree with you, you are right, it is really not that simple,
JPEG is always a headache,:(, as it is quite different from original
yuv/rgb format, it has neither fixed bits-per-sample, nor fixed
packing/bytes-per-line/per-frame, so when coding, I just hack value of
.bits_per_sample and .packing, in fact, you will see in our host driver,
if we find it is JPEG, will ignore bytes-per-line value, for example, in
pxa955_videobuf_prepare(), for jpeg, we always allocate fixed buffer
size for it (or, a better method is to allocate buffer size =
width*height/jpeg-compress-ratio).
I have 2 ideas:
1) Do you think it is reasonable to add a not-fixed define into
soc_mbus_packing:
enum soc_mbus_packing {
SOC_MBUS_PACKING_NOT_FIXED,
...
};
And then, .bits_per_sample = 0, /* indicate that sample bits is
not-fixed*/
And, in function:
s32 soc_mbus_bytes_per_line(u32 width, const struct soc_mbus_pixelfmt *mf)
{
switch (mf-packing) {
case SOC_MBUS_PACKING_NOT_FIXED:
return 0;
case SOC_MBUS_PACKING_NONE:
return width * mf-bits_per_sample / 8;
...
}
return -EINVAL;
}
2) Or, an workaround in sensor(ov5642.c), is to implement:
int (*try_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
use the member (fmt-pix-pixelformat == V4L2_PIX_FMT_JPEG) to find out
if it is jpeg. And in host driver, it calls try_fmt() into sensor. In
this way, no need to change soc-camera common code, but I feel that it
goes against with your xxx_mbus_xxx design purpose, right?
I actually prefer this one, but with an addition of V4L2_MBUS_FMT_JPEG_1X8
as per your additional üatch, but, please, also add a new packing, e.g.,
SOC_MBUS_PACKING_COMPRESSED (or SOC_MBUS_PACKING_VARIABLE?). So, that we
can cleanly translate between V4L2_MBUS_FMT_JPEG_1X8 and
V4L2_PIX_FMT_JPEG, but host drivers, that want to support this, will have
to know to calculate frame sizes in some special way, not just aborting,
if soc_mbus_bytes_per_line() returned an error. We might also consider
returning a different error code for this case, e.g., we could change the
general error case to return -ENOENT, and use -EINVAL for cases like JPEG,
where data is valid, but no valid calculation is possible.
Thanks
Guennadi
What do you think?
Please check the attachment, it is our host camera controller driver and
sensor.
Thanks a lot!
-Qing
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: 2011Äê1ÔÂ18ÈÕ 1:39
To: Qing Xu
Cc: Laurent Pinchart; Linux Media Mailing List
Subject: Re: soc-camera jpeg support?
On Mon, 17 Jan 2011, Qing Xu wrote:
Hi,
Many of our sensors support directly outputting JPEG data to camera
controller, do you feel it's reasonable to add jpeg support into
soc-camera? As it seems that there is no define in v4l2-mediabus.h which
is suitable for our case.
In principle I have nothing against this, but, I'm afraid, it is not quite
that simple. I haven't worked with such sensors myself, but, AFAIU, the
JPEG image format doesn't have fixed bytes-per-line and bytes-per-frame
values. If you add it like you propose, this would mean, that it just
delivers normal 8 bits per pixel images. OTOH, soc_mbus_bytes_per_line()
would just return -EINVAL for your JPEG format, so, unsupporting drivers
would just error out, which is not all that bad. When the first driver
decides to support JPEG, they will have to handle that error. But maybe
we'll want to return a special error code for it.
But, in fact, that is in a way my problem with your patches: you propose
extensions to generic code without showing how this is going to be used in
specific drivers. Could you show us your host driver, please? I don't
think this is still the pxa27x driver, is it?
Thanks
Guennadi
Such as:
--- a/drivers/media/video/soc_mediabus.c
+++ b/drivers/media/video/soc_mediabus.c
@@ -130,6 +130,13 @@ static const struct soc_mbus_pixelfmt mbus_fmt[] = {
.packing= SOC_MBUS_PACKING_2X8_PADLO,
.order = SOC_MBUS_ORDER_BE,
},
+ [MBUS_IDX(JPEG_1X8)] = {
+ .fourcc = V4L2_PIX_FMT_JPEG,
+ .name = JPEG,
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_NONE,
+ .order = SOC_MBUS_ORDER_LE,
+ },
};
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -41,6 +41,7 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE,
Re: [PATCH v16 1/3] davinci vpbe: changes to common files
Manjunath Hadli manjunath.ha...@ti.com writes:
Implemented a common and single mapping for DAVINCI_SYSTEM_MODULE_BASE
to be used by all davinci platforms.
Please use a more descriptive subject. This patch hs nothing to do with
VPBE, so please send it as a standalone patch.
Thanks,
Kevin
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
arch/arm/mach-davinci/common.c|4 +++-
arch/arm/mach-davinci/devices.c | 10 --
arch/arm/mach-davinci/include/mach/hardware.h |5 +
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/common.c b/arch/arm/mach-davinci/common.c
index 1d25573..949e615 100644
--- a/arch/arm/mach-davinci/common.c
+++ b/arch/arm/mach-davinci/common.c
@@ -111,7 +111,9 @@ void __init davinci_common_init(struct davinci_soc_info
*soc_info)
if (ret != 0)
goto err;
}
-
+ davinci_sysmodbase = ioremap_nocache(DAVINCI_SYSTEM_MODULE_BASE, 0x800);
+ if (!davinci_sysmodbase)
+ goto err;
return;
err:
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 22ebc64..2bff2d6 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -33,6 +33,8 @@
#define DM365_MMCSD0_BASE 0x01D11000
#define DM365_MMCSD1_BASE 0x01D0
+void __iomem *davinci_sysmodbase;
+
static struct resource i2c_resources[] = {
{
.start = DAVINCI_I2C_BASE,
@@ -209,9 +211,7 @@ void __init davinci_setup_mmc(int module, struct
davinci_mmc_config *config)
davinci_cfg_reg(DM355_SD1_DATA2);
davinci_cfg_reg(DM355_SD1_DATA3);
} else if (cpu_is_davinci_dm365()) {
- void __iomem *pupdctl1 =
- IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE + 0x7c);
-
+ void __iomem *pupdctl1 = DAVINCI_SYSMODULE_VIRT(0x7c);
/* Configure pull down control */
__raw_writel((__raw_readl(pupdctl1) ~0xfc0),
pupdctl1);
@@ -243,9 +243,7 @@ void __init davinci_setup_mmc(int module, struct
davinci_mmc_config *config)
mmcsd0_resources[2].start = IRQ_DM365_SDIOINT0;
} else if (cpu_is_davinci_dm644x()) {
/* REVISIT: should this be in board-init code? */
- void __iomem *base =
- IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
-
+ void __iomem *base = DAVINCI_SYSMODULE_VIRT(0);
/* Power-on 3.3V IO cells */
__raw_writel(0, base + DM64XX_VDD3P3V_PWDN);
/*Set up the pull regiter for MMC */
diff --git a/arch/arm/mach-davinci/include/mach/hardware.h
b/arch/arm/mach-davinci/include/mach/hardware.h
index c45ba1f..5a105c4 100644
--- a/arch/arm/mach-davinci/include/mach/hardware.h
+++ b/arch/arm/mach-davinci/include/mach/hardware.h
@@ -24,6 +24,11 @@
/* System control register offsets */
#define DM64XX_VDD3P3V_PWDN 0x48
+#ifndef __ASSEMBLER__
+ extern void __iomem *davinci_sysmodbase;
+ #define DAVINCI_SYSMODULE_VIRT(x) (davinci_sysmodbase+(x))
+#endif
+
/*
* I/O mapping
*/
--
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: 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:Tue Jan 18 19:05:40 CET 2011 git master: 1b59be2a6cdcb5a12e18d8315c07c94a624de48f git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 A linux-media.tar.bz2 archive with the latest media git sources that can be used with the media_build tree is available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday-linux-media.tar.bz2 Rename to linux-media.tar.bz2, put it in the media_build/linux directory, go to the directory and type 'make untar'. 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: [PATCH v16 2/3] davinci vpbe: platform specific additions
Manjunath Hadli manjunath.ha...@ti.com writes:
This patch implements the overall device creation for the Video
display driver, initializes the platform variables and implements
platform functions including setting video clocks.
This is dm644x specific. Please use 'davinci: dm644x: VPBE' as subject
prefix.
Kevin
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
arch/arm/mach-davinci/dm644x.c | 169
+--
arch/arm/mach-davinci/include/mach/dm644x.h |5 +
2 files changed, 163 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 9a2376b..45a89a8 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -586,12 +586,14 @@ static struct platform_device dm644x_asp_device = {
.resource = dm644x_asp_resources,
};
+#define DM644X_VPSS_REG_BASE 0x01c73400
+
static struct resource dm644x_vpss_resources[] = {
{
/* VPSS Base address */
.name = vpss,
- .start = 0x01c73400,
- .end= 0x01c73400 + 0xff,
+ .start = DM644X_VPSS_REG_BASE,
+ .end= DM644X_VPSS_REG_BASE + 0xff,
.flags = IORESOURCE_MEM,
},
};
@@ -618,6 +620,7 @@ static struct resource vpfe_resources[] = {
};
static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+
static struct resource dm644x_ccdc_resource[] = {
/* CCDC Base address */
{
@@ -654,6 +657,137 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg)
vpfe_capture_dev.dev.platform_data = cfg;
}
+#define DM644X_OSD_REG_BASE 0x01C72600
+
+static struct resource dm644x_osd_resources[] = {
+ {
+ .start = DM644X_OSD_REG_BASE,
+ .end= DM644X_OSD_REG_BASE + 0x1ff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64 dm644x_osd_dma_mask = DMA_BIT_MASK(32);
+
+static struct osd_platform_data osd_data = {
+ .vpbe_type = DM644X_VPBE,
+};
+
+static struct platform_device dm644x_osd_dev = {
+ .name = VPBE_OSD_SUBDEV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_osd_resources),
+ .resource = dm644x_osd_resources,
+ .dev = {
+ .dma_mask = dm644x_osd_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = osd_data,
+ },
+};
+
+#define DM644X_VENC_REG_BASE 0x01C72400
+
+static struct resource dm644x_venc_resources[] = {
+ /* venc registers io space */
+ {
+ .start = DM644X_VENC_REG_BASE,
+ .end= DM644X_VENC_REG_BASE + 0x17f,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64 dm644x_venc_dma_mask = DMA_BIT_MASK(32);
+
+static void __iomem *vpss_clkctl_reg;
+
+static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type, __u64
mode)
+{
+ int ret = 0;
+
+ switch (type) {
+ case VPBE_ENC_STD:
+ writel(0x18, vpss_clkctl_reg);
+ break;
+ case VPBE_ENC_DV_PRESET:
+ switch ((unsigned int)mode) {
+ case V4L2_DV_480P59_94:
+ case V4L2_DV_576P50:
+ writel(0x19, vpss_clkctl_reg);
+ break;
+ case V4L2_DV_720P60:
+ case V4L2_DV_1080I60:
+ case V4L2_DV_1080P30:
+ /*
+ * For HD, use external clock source since
+ * HD requires higher clock rate
+ */
+ writel(0xa, vpss_clkctl_reg);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ break;
+ default:
+ ret = -EINVAL;
+ }
+ return ret;
+}
+
+static u64 vpbe_display_dma_mask = DMA_BIT_MASK(32);
+
+static struct resource dm644x_v4l2_disp_resources[] = {
+ {
+ .start = IRQ_VENCINT,
+ .end= IRQ_VENCINT,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device vpbe_v4l2_display = {
+ .name = vpbe-v4l2,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_v4l2_disp_resources),
+ .resource = dm644x_v4l2_disp_resources,
+ .dev = {
+ .dma_mask = vpbe_display_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
+struct venc_platform_data dm644x_venc_pdata = {
+ .venc_type = DM644X_VPBE,
+ .setup_clock= dm644x_venc_setup_clock,
+};
+
+static struct platform_device dm644x_venc_dev = {
+ .name
Re: [PATCH 2/9 v2] Altera FPGA based CI driver module.
В сообщении от 16 января 2011 19:52:38 автор Mauro Carvalho Chehab написал: Em 02-01-2011 10:01, Igor M. Liplianin escreveu: An Altera FPGA CI module for NetUP Dual DVB-T/C RF CI card. Signed-off-by: Igor M. Liplianin liplia...@netup.ru Igor, There's something wrong with this patch. I got lots of error after applying it: drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_read_attribute_mem': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:304: multiple definition of `netup_ci_read_attribute_mem' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/medi a/video/cx23885/cimax2.c:241: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_op_cam': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:269: multiple definition of `netup_ci_op_cam' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/medi a/video/cx23885/cimax2.c:171: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_slot_shutdown': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:364: multiple definition of `netup_ci_slot_shutdown' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/medi a/video/cx23885/cimax2.c:293: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_slot_ts_ctl': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:370: multiple definition of `netup_ci_slot_ts_ctl' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/medi a/video/cx23885/cimax2.c:320: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_write_cam_ctl': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:322: multiple definition of `netup_ci_write_cam_ctl' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/medi a/video/cx23885/cimax2.c:259: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_read_cam_ctl': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:315: multiple definition of `netup_ci_read_cam_ctl' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/medi a/video/cx23885/cimax2.c:252: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_write_attribute_mem': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:310: multiple definition of `netup_ci_write_attribute_mem' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/medi a/video/cx23885/cimax2.c:247: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_poll_ci_slot_status': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:448: multiple definition of `netup_poll_ci_slot_status' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/medi a/video/cx23885/cimax2.c:403: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_slot_reset': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:327: multiple definition of `netup_ci_slot_reset' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/medi a/video/cx23885/cimax2.c:264: first defined here Please fix it and submit a new version. The better is to replace all those new symbols to start with altera_ci. I see, allyesconfig... While here, please, on the first patch, move the Altera FPGA driver to staging, to give people some time do discuss about it. It means that cx23885 driver will depend on staging. Is it OK? PS.: there are a few CodingStyle errors on this patch. Please always review your patches with ./scripts/checkpatch.pl. I'll do it. Thanks! Mauro -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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.38] Compile error fix
Hi Mauro, That beautiful 'OK' from the daily build disappeared again. This should bring it back :-) Regards, Hans The following changes since commit fd4564a8c4f23b5ea6526180898ca2aedda2444e: Jarod Wilson (1): [media] staging/lirc: fix mem leaks and ptr err usage are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git cxd2099 Hans Verkuil (1): cxd2099: fix 'multiple definition' compile errors drivers/staging/cxd2099/cxd2099.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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][_COMPAT_H] git://linuxtv.org/media_build.git Legacy issues
On Mon, 2011-01-17 at 21:22 -0500, Andy Walls wrote: On Mon, 2011-01-17 at 22:59 +, Malcolm Priestley wrote: Clean up legacy issues for error free build on Kernel 2.6.37. Today while testing on Kernel 2.6.35 latest tarball throws error with alloc_ordered_workqueue undefined on Kernels less than 2.6.37. defined back to create_singlethread_workqueue. Please test on other kernel versions. Tested-on 2.6.35/37 by: Malcolm Priestley tvbox...@gmail.com +#define alloc_ordered_workqueue(a,b) create_singlethread_workqueue(a) That will get cx18 to compile. However, I can tell you without testing, the latest cx18 driver could badly affect system event processing performance on older kernels. This is because another change happened at the same time as the change to call alloc_ordered_workqueue(). A kernel version before that, CMWQ was added to the kernel, so there was no longer a need for the cx18_out_work workqueue. So now the cx18_out_work workqueue has been removed from the cx18 driver. In the older kernels without CMWQ and without the cx18_out_work workqueue, outgoing cx18 buffer work will get queued to the [keventd/M] kernel threads. Unrelated system work being processed by [keventd/M] threads will regularly find itself *waiting for the CX23418 hardware* to respond to firmware commands. It would be better to not allow the newest cx18 driver version to compile on older kernels. Yes, after review, it would be wise to disable the cx18 driver. However, there are more problems with the media_build today on all kernels. For now the patch is withdrawn. Regards malcolm -- 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] v4l: OMAP3 ISP CCDC: Add support for 8bit greyscale sensors
Adds support for V4L2_MBUS_FMT_Y8_1X8 format and 8bit data width in
synchronous interface.
When in 8bit mode don't apply DC substraction of 64 per default as this would
remove 1/4 of the sensor range.
When using V4L2_MBUS_FMT_Y8_1X8 (or possibly another 8bit per pixel) mode
set the CDCC to output 8bit per pixel instead of 16bit.
Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
drivers/media/video/isp/ispccdc.c | 22 ++
drivers/media/video/isp/ispvideo.c |2 ++
2 files changed, 20 insertions(+), 4 deletions(-)
Changes since first version:
- forward ported to current media.git
diff --git a/drivers/media/video/isp/ispccdc.c
b/drivers/media/video/isp/ispccdc.c
index 578c8bf..c7397c9 100644
--- a/drivers/media/video/isp/ispccdc.c
+++ b/drivers/media/video/isp/ispccdc.c
@@ -43,6 +43,7 @@ __ccdc_get_format(struct isp_ccdc_device *ccdc, struct
v4l2_subdev_fh *fh,
unsigned int pad, enum v4l2_subdev_format_whence which);
static const unsigned int ccdc_fmts[] = {
+ V4L2_MBUS_FMT_Y8_1X8,
V4L2_MBUS_FMT_SGRBG10_1X10,
V4L2_MBUS_FMT_SRGGB10_1X10,
V4L2_MBUS_FMT_SBGGR10_1X10,
@@ -1127,6 +1128,9 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
ccdc-syncif.datsz = pdata ? pdata-width : 10;
ispccdc_config_sync_if(ccdc, ccdc-syncif);
+ /* CCDC_PAD_SINK */
+ format = ccdc-formats[CCDC_PAD_SINK];
+
syn_mode = isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
/* Use the raw, unprocessed data when writing to memory. The H3A and
@@ -1144,10 +1148,15 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
else
syn_mode = ~ISPCCDC_SYN_MODE_SDR2RSZ;
- isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
+ /* Use PACK8 mode for 1byte per pixel formats */
- /* CCDC_PAD_SINK */
- format = ccdc-formats[CCDC_PAD_SINK];
+ if (isp_video_format_info(format-code)-bpp = 8)
+ syn_mode |= ISPCCDC_SYN_MODE_PACK8;
+ else
+ syn_mode = ~ISPCCDC_SYN_MODE_PACK8;
+
+
+ isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
/* Mosaic filter */
switch (format-code) {
@@ -2244,7 +2253,12 @@ int isp_ccdc_init(struct isp_device *isp)
ccdc-syncif.vdpol = 0;
ccdc-clamp.oblen = 0;
- ccdc-clamp.dcsubval = 64;
+
+ if (isp-pdata-subdevs-interface == ISP_INTERFACE_PARALLEL
+isp-pdata-subdevs-bus.parallel.width = 8)
+ ccdc-clamp.dcsubval = 0;
+ else
+ ccdc-clamp.dcsubval = 64;
ccdc-vpcfg.pixelclk = 0;
diff --git a/drivers/media/video/isp/ispvideo.c
b/drivers/media/video/isp/ispvideo.c
index 5f984e4..cd3d331 100644
--- a/drivers/media/video/isp/ispvideo.c
+++ b/drivers/media/video/isp/ispvideo.c
@@ -221,6 +221,8 @@ isp_video_check_format(struct isp_video *video, struct
isp_video_fh *vfh)
}
static struct isp_format_info formats[] = {
+ { V4L2_MBUS_FMT_Y8_1X8, V4L2_MBUS_FMT_Y8_1X8,
+ V4L2_MBUS_FMT_Y8_1X8, V4L2_PIX_FMT_GREY, 8, },
{ V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8, V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8,
V4L2_MBUS_FMT_SGRBG10_1X10, V4L2_PIX_FMT_SGRBG10DPCM8, 8, },
{ V4L2_MBUS_FMT_SBGGR10_1X10, V4L2_MBUS_FMT_SBGGR10_1X10,
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9 v2] Altera FPGA based CI driver module.
Em 18-01-2011 17:23, Igor M. Liplianin escreveu: В сообщении от 16 января 2011 19:52:38 автор Mauro Carvalho Chehab написал: Em 02-01-2011 10:01, Igor M. Liplianin escreveu: An Altera FPGA CI module for NetUP Dual DVB-T/C RF CI card. Signed-off-by: Igor M. Liplianin liplia...@netup.ru Igor, There's something wrong with this patch. I got lots of error after applying it: drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_read_attribute_mem': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:304: multiple definition of `netup_ci_read_attribute_mem' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/medi a/video/cx23885/cimax2.c:241: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_op_cam': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:269: multiple definition of `netup_ci_op_cam' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/medi a/video/cx23885/cimax2.c:171: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_slot_shutdown': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:364: multiple definition of `netup_ci_slot_shutdown' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/medi a/video/cx23885/cimax2.c:293: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_slot_ts_ctl': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:370: multiple definition of `netup_ci_slot_ts_ctl' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/medi a/video/cx23885/cimax2.c:320: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_write_cam_ctl': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:322: multiple definition of `netup_ci_write_cam_ctl' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/medi a/video/cx23885/cimax2.c:259: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_read_cam_ctl': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:315: multiple definition of `netup_ci_read_cam_ctl' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/medi a/video/cx23885/cimax2.c:252: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_write_attribute_mem': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:310: multiple definition of `netup_ci_write_attribute_mem' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/medi a/video/cx23885/cimax2.c:247: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_poll_ci_slot_status': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:448: multiple definition of `netup_poll_ci_slot_status' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/medi a/video/cx23885/cimax2.c:403: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_slot_reset': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:327: multiple definition of `netup_ci_slot_reset' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/medi a/video/cx23885/cimax2.c:264: first defined here Please fix it and submit a new version. The better is to replace all those new symbols to start with altera_ci. I see, allyesconfig... Yes. While here, please, on the first patch, move the Altera FPGA driver to staging, to give people some time do discuss about it. It means that cx23885 driver will depend on staging. Is it OK? The idea is to enable the Altera-dependent part of cx23885 only if compiled. There's no need to make the entire cx2388x dependent of Altera driver. PS.: there are a few CodingStyle errors on this patch. Please always review your patches with ./scripts/checkpatch.pl. I'll do it. Ok, thanks! Thanks! 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
Upstreaming syntek driver
Hello, I'm a lucky owner of a Syntek USB webcam (embedded on my Asus laptop); as you might know Nicolas (CC) wrote a driver for these cams[1][2], but it's still not included in mainline kernel. Since I'd rather save myself and the other users the pain of compiling an out-of-tree driver I'm offering my help to make the changes necessary to see this driver upstreamed; I'm already a maintainer of another driver (in hwmon), so I'm familiar with the development process. From a quick overview of the code I've spotted a few problems: - minor style issues, trivially dealt with - missing cleanups in error paths, idem - possible memory leak, reported on the bug tracker - requires investigation - big switch statements for all the models, could be simplified with function pointers Another objection could be that the initialization is basically writing magic numbers into magic registers... I guess that Nicolas recorded the initialization sequence with a USB sniffer. No solution for this one; does anybody have a contact inside Syntek? Are there other issues blocking the inclusion of this driver? Luca [1] http://syntekdriver.sourceforge.net/ [2] http://syntekdriver.svn.sourceforge.net/viewvc/syntekdriver/trunk/ -- 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] v4l: Add driver for Micron MT9M032 camera sensor
The MT9M032 is a parallel 1284x812 sensor from Micron controlled through I2C.
The driver creates a V4L2 subdevice. It currently supports cropping, gain,
exposure and v/h flipping controls in monochrome mode with an
external pixel clock.
Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile|1 +
drivers/media/video/mt9m032.c | 834 +++
drivers/media/video/mt9m032.h | 38 ++
include/media/v4l2-chip-ident.h |1 +
5 files changed, 881 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mt9m032.c
create mode 100644 drivers/media/video/mt9m032.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 9fad1a6..f2d5f80 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -773,6 +773,13 @@ config SOC_CAMERA_MT9M001
This driver supports MT9M001 cameras from Micron, monochrome
and colour models.
+config VIDEO_MT9M032
+ tristate MT9M032 camera sensor support
+ depends on I2C VIDEO_V4L2
+ help
+ This driver supports MT9M032 cameras from Micron, monochrome
+ models only.
+
config SOC_CAMERA_MT9M111
tristate mt9m111, mt9m112 and mt9m131 support
depends on SOC_CAMERA I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 8f70b06..3e7299f 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
+obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
diff --git a/drivers/media/video/mt9m032.c b/drivers/media/video/mt9m032.c
new file mode 100644
index 000..fe6af7b
--- /dev/null
+++ b/drivers/media/video/mt9m032.c
@@ -0,0 +1,834 @@
+/*
+ * Driver for MT9M032 CMOS Image Sensor from Micron
+ *
+ * Copyright (C) 2010-2011 Lund Engineering
+ * Contact: Gil Lund gwl...@lundeng.com
+ * Author: Martin Hostettler mar...@neutronstar.dyndns.org
+ *
+ * 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 St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/v4l2-mediabus.h
+
+#include media/media-entity.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+
+#include mt9m032.h
+
+#define MT9M032_CHIP_VERSION 0x00
+#define MT9M032_ROW_START 0x01
+#define MT9M032_COLUMN_START 0x02
+#define MT9M032_ROW_SIZE 0x03
+#define MT9M032_COLUMN_SIZE0x04
+#define MT9M032_HBLANK 0x05
+#define MT9M032_VBLANK 0x06
+#define MT9M032_SHUTTER_WIDTH_HIGH 0x08
+#define MT9M032_SHUTTER_WIDTH_LOW 0x09
+#define MT9M032_PIX_CLK_CTRL 0x0A
+#define MT9M032_RESTART0x0B
+#define MT9M032_RESET 0x0D
+#define MT9M032_PLL_CONFIG10x11
+#define MT9M032_READ_MODE1 0x1E
+#define MT9M032_READ_MODE2 0x20
+#define MT9M032_GAIN_GREEN10x2B
+#define MT9M032_GAIN_BLUE 0x2C
+#define MT9M032_GAIN_RED 0x2D
+#define MT9M032_GAIN_GREEN20x2E
+/* write only */
+#define MT9M032_GAIN_ALL 0x35
+#define MT9M032_FORMATTER1 0x9E
+#define MT9M032_FORMATTER2 0x9F
+
+#define to_mt9m032(sd) container_of(sd, struct mt9m032, subdev)
+#define to_dev(sensor) ((struct i2c_client
*)v4l2_get_subdevdata(sensor-subdev))-dev
+
+struct mt9m032 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct mt9m032_platform_data *pdata;
+ struct v4l2_ctrl_handler ctrls;
+
+ bool streaming;
+
+ int pix_clock;
+
+ struct v4l2_mbus_framefmt format; /* height and width always the
same as in crop */
+ struct v4l2_rect crop;
+ struct v4l2_fract frame_interval;
+
+ struct v4l2_ctrl *hflip, *vflip, *gain, *exposure;
+};
+
+
+static int mt9m032_read_reg(struct i2c_client *client,
[PATCH RFC] arm: omap3evm: Add support for an MT9M032 based camera board.
Adds board support for an MT9M032 based camera to omap3evm.
Sigend-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-omap3evm-camera.c | 177 +++
2 files changed, 178 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
This patch depends on the recent not yet mainline media controller framework
and omap3-isp driver availible at git.linuxtv.org/pinchartl/media.git.
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 60e51bc..5f43cc5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -132,6 +132,7 @@ obj-$(CONFIG_MACH_OMAP3_TORPEDO)+=
board-omap3logic.o \
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \
+ board-omap3evm-camera.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
b/arch/arm/mach-omap2/board-omap3evm-camera.c
new file mode 100644
index 000..ea82a49
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
@@ -0,0 +1,177 @@
+/*
+ * Copyright (C) 2010-2011 Lund Engineering
+ * Contact: Gil Lund gwl...@lundeng.com
+ * Author: Martin Hostettler mar...@neutronstar.dyndns.org
+ *
+ * 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 St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/i2c.h
+#include linux/init.h
+#include linux/platform_device.h
+
+#include asm/gpio.h
+#include plat/mux.h
+#include mux.h
+
+#include ../../../drivers/media/video/isp/isp.h
+#include ../../../drivers/media/video/mt9m032.h
+
+#include devices.h
+
+#define EVM_TWL_GPIO_BASE OMAP_MAX_GPIO_LINES
+#define GPIO98_VID_DEC_RES 98
+#define nCAM_VD_SEL157
+
+#define MT9M032_I2C_BUS_NUM2
+
+
+enum omap3evmdc_mux {
+ MUX_TVP5146,
+ MUX_CAMERA_SENSOR,
+ MUX_EXP_CAMERA_SENSOR,
+};
+
+/**
+ * omap3evm_set_mux - Sets mux to enable signal routing to
+ * different peripherals present on new EVM board
+ * @mux_id: enum, mux id to enable
+ *
+ * Returns 0 for success or a negative error code
+ */
+static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
+{
+ /* Set GPIO6 = 1 */
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 6, 1);
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+
+ switch (mux_id) {
+ case MUX_TVP5146:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 1);
+ break;
+
+ case MUX_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 0);
+ break;
+
+ case MUX_EXP_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 1);
+ break;
+
+ default:
+ pr_err(omap3evm-camera: Invalid mux id #%d\n, mux_id);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static struct mt9m032_platform_data mt9m032_platform_data = {
+ .ext_clock = 1350,
+ .pll_pre_div = 6,
+ .pll_mul = 120,
+ .pll_out_div = 5,
+ .invert_pixclock = 1,
+};
+
+static struct i2c_board_info camera_i2c_devices[] = {
+ {
+ I2C_BOARD_INFO(MT9M032_NAME, MT9M032_I2C_ADDR),
+ .platform_data = mt9m032_platform_data,
+ },
+};
+
+static struct isp_subdev_i2c_board_info camera_i2c_subdevs[] = {
+ {
+ .board_info = camera_i2c_devices[0],
+ .i2c_adapter_id = MT9M032_I2C_BUS_NUM,
+ },
+ {},
+};
+
+static struct isp_v4l2_subdevs_group camera_subdevs[] = {
+ {
+ .subdevs = camera_i2c_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .data_lane_shift = 1,
+ .clk_pol = 0,
+ .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
+ .width = 8,
+ }
+ },
+ },
+
Re: Upstreaming syntek driver
On Tuesday, January 18, 2011 23:17:11 Luca Tettamanti wrote: Hello, I'm a lucky owner of a Syntek USB webcam (embedded on my Asus laptop); as you might know Nicolas (CC) wrote a driver for these cams[1][2], but it's still not included in mainline kernel. Since I'd rather save myself and the other users the pain of compiling an out-of-tree driver I'm offering my help to make the changes necessary to see this driver upstreamed; I'm already a maintainer of another driver (in hwmon), so I'm familiar with the development process. From a quick overview of the code I've spotted a few problems: - minor style issues, trivially dealt with - missing cleanups in error paths, idem - possible memory leak, reported on the bug tracker - requires investigation - big switch statements for all the models, could be simplified with function pointers Another objection could be that the initialization is basically writing magic numbers into magic registers... I guess that Nicolas recorded the initialization sequence with a USB sniffer. No solution for this one; does anybody have a contact inside Syntek? Are there other issues blocking the inclusion of this driver? After a quick scan through the sources in svn I found the following (in no particular order): - Supports easycap model with ID 05e1:0408: a driver for this model is now in driver/staging/easycap. - format conversion must be moved to libv4lconvert (if that can't already be used out of the box). Ditto for software brightness correction. - kill off the sysfs bits - kill off V4L1 - use the new control framework for the control handling - use video_ioctl2 instead of the current ioctl function - use unlocked_ioctl instead of ioctl But probably the first step should be to see if this can't be made part of the gspca driver. I can't help thinking that that would be the best approach. But I guess the gspca developers can give a better idea of how hard that is. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l: Add driver for Micron MT9M032 camera sensor
Hi Martin,
On Tuesday, January 18, 2011 23:18:42 Martin Hostettler wrote:
The MT9M032 is a parallel 1284x812 sensor from Micron controlled through I2C.
The driver creates a V4L2 subdevice. It currently supports cropping, gain,
exposure and v/h flipping controls in monochrome mode with an
external pixel clock.
Now, this is a truly bleeding edge driver :-)
Pads aren't even merged yet!
Got some small comments:
Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile|1 +
drivers/media/video/mt9m032.c | 834
+++
drivers/media/video/mt9m032.h | 38 ++
include/media/v4l2-chip-ident.h |1 +
5 files changed, 881 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mt9m032.c
create mode 100644 drivers/media/video/mt9m032.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 9fad1a6..f2d5f80 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -773,6 +773,13 @@ config SOC_CAMERA_MT9M001
This driver supports MT9M001 cameras from Micron, monochrome
and colour models.
+config VIDEO_MT9M032
+ tristate MT9M032 camera sensor support
+ depends on I2C VIDEO_V4L2
+ help
+ This driver supports MT9M032 cameras from Micron, monochrome
+ models only.
+
config SOC_CAMERA_MT9M111
tristate mt9m111, mt9m112 and mt9m131 support
depends on SOC_CAMERA I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 8f70b06..3e7299f 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
+obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
diff --git a/drivers/media/video/mt9m032.c b/drivers/media/video/mt9m032.c
new file mode 100644
index 000..fe6af7b
--- /dev/null
+++ b/drivers/media/video/mt9m032.c
@@ -0,0 +1,834 @@
+/*
+ * Driver for MT9M032 CMOS Image Sensor from Micron
+ *
+ * Copyright (C) 2010-2011 Lund Engineering
+ * Contact: Gil Lund gwl...@lundeng.com
+ * Author: Martin Hostettler mar...@neutronstar.dyndns.org
+ *
+ * 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 St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/v4l2-mediabus.h
+
+#include media/media-entity.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+
+#include mt9m032.h
+
+#define MT9M032_CHIP_VERSION 0x00
+#define MT9M032_ROW_START0x01
+#define MT9M032_COLUMN_START 0x02
+#define MT9M032_ROW_SIZE 0x03
+#define MT9M032_COLUMN_SIZE 0x04
+#define MT9M032_HBLANK 0x05
+#define MT9M032_VBLANK 0x06
+#define MT9M032_SHUTTER_WIDTH_HIGH 0x08
+#define MT9M032_SHUTTER_WIDTH_LOW0x09
+#define MT9M032_PIX_CLK_CTRL 0x0A
+#define MT9M032_RESTART 0x0B
+#define MT9M032_RESET0x0D
+#define MT9M032_PLL_CONFIG1 0x11
+#define MT9M032_READ_MODE1 0x1E
+#define MT9M032_READ_MODE2 0x20
+#define MT9M032_GAIN_GREEN1 0x2B
+#define MT9M032_GAIN_BLUE0x2C
+#define MT9M032_GAIN_RED 0x2D
+#define MT9M032_GAIN_GREEN2 0x2E
+/* write only */
+#define MT9M032_GAIN_ALL 0x35
+#define MT9M032_FORMATTER1 0x9E
+#define MT9M032_FORMATTER2 0x9F
+
+#define to_mt9m032(sd) container_of(sd, struct mt9m032, subdev)
+#define to_dev(sensor) ((struct i2c_client
*)v4l2_get_subdevdata(sensor-subdev))-dev
+
+struct mt9m032 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct mt9m032_platform_data *pdata;
+ struct v4l2_ctrl_handler ctrls;
+
+ bool streaming;
+
+ int pix_clock;
+
+ struct
Re: [PATCH V2] v4l: OMAP3 ISP CCDC: Add support for 8bit greyscale sensors
Hi Martin,
Thanks for the patch. One comment below.
On Tuesday 18 January 2011 22:27:42 Martin Hostettler wrote:
Adds support for V4L2_MBUS_FMT_Y8_1X8 format and 8bit data width in
synchronous interface.
When in 8bit mode don't apply DC substraction of 64 per default as this
would remove 1/4 of the sensor range.
When using V4L2_MBUS_FMT_Y8_1X8 (or possibly another 8bit per pixel) mode
set the CDCC to output 8bit per pixel instead of 16bit.
Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
drivers/media/video/isp/ispccdc.c | 22 ++
drivers/media/video/isp/ispvideo.c |2 ++
2 files changed, 20 insertions(+), 4 deletions(-)
Changes since first version:
- forward ported to current media.git
diff --git a/drivers/media/video/isp/ispccdc.c
b/drivers/media/video/isp/ispccdc.c index 578c8bf..c7397c9 100644
--- a/drivers/media/video/isp/ispccdc.c
+++ b/drivers/media/video/isp/ispccdc.c
@@ -43,6 +43,7 @@ __ccdc_get_format(struct isp_ccdc_device *ccdc, struct
v4l2_subdev_fh *fh, unsigned int pad, enum v4l2_subdev_format_whence
which);
static const unsigned int ccdc_fmts[] = {
+ V4L2_MBUS_FMT_Y8_1X8,
V4L2_MBUS_FMT_SGRBG10_1X10,
V4L2_MBUS_FMT_SRGGB10_1X10,
V4L2_MBUS_FMT_SBGGR10_1X10,
@@ -1127,6 +1128,9 @@ static void ccdc_configure(struct isp_ccdc_device
*ccdc) ccdc-syncif.datsz = pdata ? pdata-width : 10;
ispccdc_config_sync_if(ccdc, ccdc-syncif);
+ /* CCDC_PAD_SINK */
+ format = ccdc-formats[CCDC_PAD_SINK];
+
syn_mode = isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
/* Use the raw, unprocessed data when writing to memory. The H3A and
@@ -1144,10 +1148,15 @@ static void ccdc_configure(struct isp_ccdc_device
*ccdc) else
syn_mode = ~ISPCCDC_SYN_MODE_SDR2RSZ;
- isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
+ /* Use PACK8 mode for 1byte per pixel formats */
- /* CCDC_PAD_SINK */
- format = ccdc-formats[CCDC_PAD_SINK];
+ if (isp_video_format_info(format-code)-bpp = 8)
+ syn_mode |= ISPCCDC_SYN_MODE_PACK8;
+ else
+ syn_mode = ~ISPCCDC_SYN_MODE_PACK8;
+
+
+ isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
/* Mosaic filter */
switch (format-code) {
@@ -2244,7 +2253,12 @@ int isp_ccdc_init(struct isp_device *isp)
ccdc-syncif.vdpol = 0;
ccdc-clamp.oblen = 0;
- ccdc-clamp.dcsubval = 64;
+
+ if (isp-pdata-subdevs-interface == ISP_INTERFACE_PARALLEL
+ isp-pdata-subdevs-bus.parallel.width = 8)
+ ccdc-clamp.dcsubval = 0;
+ else
+ ccdc-clamp.dcsubval = 64;
I don't like this too much. What happens if you have several sensors connected
to the system with different bus width ?
ccdc-vpcfg.pixelclk = 0;
diff --git a/drivers/media/video/isp/ispvideo.c
b/drivers/media/video/isp/ispvideo.c index 5f984e4..cd3d331 100644
--- a/drivers/media/video/isp/ispvideo.c
+++ b/drivers/media/video/isp/ispvideo.c
@@ -221,6 +221,8 @@ isp_video_check_format(struct isp_video *video, struct
isp_video_fh *vfh) }
static struct isp_format_info formats[] = {
+ { V4L2_MBUS_FMT_Y8_1X8, V4L2_MBUS_FMT_Y8_1X8,
+ V4L2_MBUS_FMT_Y8_1X8, V4L2_PIX_FMT_GREY, 8, },
{ V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8, V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8,
V4L2_MBUS_FMT_SGRBG10_1X10, V4L2_PIX_FMT_SGRBG10DPCM8, 8, },
{ V4L2_MBUS_FMT_SBGGR10_1X10, V4L2_MBUS_FMT_SBGGR10_1X10,
--
Regards,
Laurent Pinchart
--
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: link error w/ media-0006-sensors
Hi Michael, On Tuesday 18 January 2011 17:14:37 Michael Jones wrote: Hi Laurent Sakari, On Laurent's media-0006-sensors branch, when compiling with CONFIG_VIDEO_OMAP3=m, I got the following linking error: ERROR: omap_pm_set_min_bus_tput [drivers/media/video/isp/omap3-isp.ko] undefined! I can get rid of the error with the patch below. But as always, I wonder: Why didn't anybody else come across this error? Are you all compiling with VIDEO_OMAP3=y? Is there a config file somewhere I can see where someone is using that? And would anything be wrong with the patch below? Martin Hostettler sent the same patch to linux-omap today ([PATCH] OMAP: PM: Export omap_pm_set_min_bus_tput to modules). See Please see Paul Wamsley's answer on the list. -- Regards, Laurent Pinchart -- 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 RFC] arm: omap3evm: Add support for an MT9M032 based camera board.
Hi Martin,
Thanks for the patch.
On Tuesday 18 January 2011 23:32:16 Martin Hostettler wrote:
Adds board support for an MT9M032 based camera to omap3evm.
Sigend-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-omap3evm-camera.c | 177
2 files changed, 178 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
Is there a special reason to add camera support to a separate file ?
Of course not all OMAP3 EVM systems will use an MT9M032 sensor, so some kind
of modularity (and if possible runtime configuration) will be needed.
[snip]
diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
b/arch/arm/mach-omap2/board-omap3evm-camera.c new file mode 100644
index 000..ea82a49
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
@@ -0,0 +1,177 @@
[snip]
+/*
+ * Copyright (C) 2010-2011 Lund Engineering
+ * Contact: Gil Lund gwl...@lundeng.com
+ * Author: Martin Hostettler mar...@neutronstar.dyndns.org
+ *
+ * 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 St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/i2c.h
+#include linux/init.h
+#include linux/platform_device.h
+
+#include asm/gpio.h
+#include plat/mux.h
+#include mux.h
+
+#include ../../../drivers/media/video/isp/isp.h
+#include ../../../drivers/media/video/mt9m032.h
mt9m032.h should be moved to include/media (the same is true for isp.h as
well, I'll probably split it and move the part required by board files to
include/media/omap3isp.h).
+#include devices.h
+
+#define EVM_TWL_GPIO_BASE OMAP_MAX_GPIO_LINES
+#define GPIO98_VID_DEC_RES 98
+#define nCAM_VD_SEL 157
+
+#define MT9M032_I2C_BUS_NUM 2
+
+
+enum omap3evmdc_mux {
+ MUX_TVP5146,
+ MUX_CAMERA_SENSOR,
+ MUX_EXP_CAMERA_SENSOR,
+};
+
+/**
+ * omap3evm_set_mux - Sets mux to enable signal routing to
+ * different peripherals present on new EVM
board + * @mux_id: enum, mux id to enable
+ *
+ * Returns 0 for success or a negative error code
+ */
+static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
+{
+ /* Set GPIO6 = 1 */
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 6, 1);
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+
+ switch (mux_id) {
+ case MUX_TVP5146:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 1);
+ break;
+
+ case MUX_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 0);
+ break;
+
+ case MUX_EXP_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 1);
+ break;
+
+ default:
+ pr_err(omap3evm-camera: Invalid mux id #%d\n, mux_id);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int __init camera_init(void)
+{
+ omap_mux_init_gpio(nCAM_VD_SEL, OMAP_PIN_OUTPUT);
+ if (gpio_request(nCAM_VD_SEL, nCAM_VD_SEL) 0) {
+ pr_err(omap3evm-camera: Failed to get GPIO nCAM_VD_SEL(%d)\n,
+nCAM_VD_SEL);
+ goto err;
You can return -EINVAL directly here. This removes the need for the 'err'
label.
+ }
+ if (gpio_direction_output(nCAM_VD_SEL, 1) 0) {
+ pr_err(omap3evm-camera: Failed to set GPIO nCAM_VD_SEL(%d)
direction\n, + nCAM_VD_SEL);
+ goto err_vdsel;
+ }
+
+ if (gpio_request(EVM_TWL_GPIO_BASE + 2, T2_GPIO2) 0) {
+ pr_err(omap3evm-camera: Failed to get GPIO T2_GPIO2(%d)\n,
+EVM_TWL_GPIO_BASE + 2);
+ goto err_vdsel;
+ }
+ if (gpio_direction_output(EVM_TWL_GPIO_BASE + 2, 0) 0) {
+ pr_err(omap3evm-camera: Failed to set GPIO T2_GPIO2(%d)
direction\n,
+EVM_TWL_GPIO_BASE + 2);
+ goto err_2;
+ }
+
+ if (gpio_request(EVM_TWL_GPIO_BASE + 8, nCAM_VD_EN) 0) {
+ pr_err(omap3evm-camera: Failed to get GPIO nCAM_VD_EN(%d)\n,
+EVM_TWL_GPIO_BASE + 8);
+ goto err_2;
+ }
+ if (gpio_direction_output(EVM_TWL_GPIO_BASE + 8, 0) 0) {
+
Re: [PATCH] v4l: Add driver for Micron MT9M032 camera sensor
Hi Hans and Martin,
On Wednesday 19 January 2011 00:05:10 Hans Verkuil wrote:
On Tuesday, January 18, 2011 23:18:42 Martin Hostettler wrote:
[snip]
+ return mt9m032_write_reg(client, MT9M032_VBLANK,
additional_blanking_rows);
I've found it easier to do the v4l2_subdev to i2c_client conversion at the
lowest level: the read/write register functions. That way the conversion is
done at only a few places, rather than at every place these read/write reg
functions are called. Just my opinion, though.
I agree with this.
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+static long mt9m032_ioctl(struct v4l2_subdev *sd, unsigned int cmd, void
*arg) +{
+ if (cmd == VIDIOC_DBG_G_REGISTER || cmd == VIDIOC_DBG_S_REGISTER) {
+ struct v4l2_dbg_register *p = arg;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ if (cmd == VIDIOC_DBG_G_REGISTER)
+ return v4l2_subdev_call(sd, core, g_register, p);
+ else
+ return v4l2_subdev_call(sd, core, s_register, p);
+ } else {
+ return -ENOIOCTLCMD;
+ }
+}
Huh? Ah, I get it. This is for when the user uses the subdev's device node
directly. This is not good, the v4l2 framework should do translate this to
g/s_register.
Agreed.
The same should be done for g_chip_ident, I guess.
I don't think we need g_chip_ident for subdev nodes, do we ?
+#endif
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l: Add driver for Micron MT9M032 camera sensor
Hi Martin,
Thanks for the patch.
On Tuesday 18 January 2011 23:18:42 Martin Hostettler wrote:
The MT9M032 is a parallel 1284x812 sensor from Micron controlled through
I2C.
The driver creates a V4L2 subdevice. It currently supports cropping, gain,
exposure and v/h flipping controls in monochrome mode with an
external pixel clock.
Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile|1 +
drivers/media/video/mt9m032.c | 834
drivers/media/video/mt9m032.h | 38 ++
include/media/v4l2-chip-ident.h |1 +
5 files changed, 881 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mt9m032.c
create mode 100644 drivers/media/video/mt9m032.h
[snip]
diff --git a/drivers/media/video/mt9m032.c b/drivers/media/video/mt9m032.c
new file mode 100644
index 000..fe6af7b
--- /dev/null
+++ b/drivers/media/video/mt9m032.c
@@ -0,0 +1,834 @@
+/*
+ * Driver for MT9M032 CMOS Image Sensor from Micron
+ *
+ * Copyright (C) 2010-2011 Lund Engineering
+ * Contact: Gil Lund gwl...@lundeng.com
+ * Author: Martin Hostettler mar...@neutronstar.dyndns.org
+ *
+ * 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 St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/v4l2-mediabus.h
+
+#include media/media-entity.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+
+#include mt9m032.h
+
+#define MT9M032_CHIP_VERSION 0x00
+#define MT9M032_ROW_START0x01
+#define MT9M032_COLUMN_START 0x02
+#define MT9M032_ROW_SIZE 0x03
+#define MT9M032_COLUMN_SIZE 0x04
+#define MT9M032_HBLANK 0x05
+#define MT9M032_VBLANK 0x06
+#define MT9M032_SHUTTER_WIDTH_HIGH 0x08
+#define MT9M032_SHUTTER_WIDTH_LOW0x09
+#define MT9M032_PIX_CLK_CTRL 0x0A
Kernel code usually uses lowercase hex constants.
+#define MT9M032_RESTART 0x0B
+#define MT9M032_RESET0x0D
+#define MT9M032_PLL_CONFIG1 0x11
+#define MT9M032_READ_MODE1 0x1E
+#define MT9M032_READ_MODE2 0x20
+#define MT9M032_GAIN_GREEN1 0x2B
+#define MT9M032_GAIN_BLUE0x2C
+#define MT9M032_GAIN_RED 0x2D
+#define MT9M032_GAIN_GREEN2 0x2E
+/* write only */
+#define MT9M032_GAIN_ALL 0x35
+#define MT9M032_FORMATTER1 0x9E
+#define MT9M032_FORMATTER2 0x9F
+
+#define to_mt9m032(sd) container_of(sd, struct mt9m032, subdev)
+#define to_dev(sensor) ((struct
i2c_client*)v4l2_get_subdevdata(sensor-
subdev))-dev
+
+struct mt9m032 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct mt9m032_platform_data *pdata;
+ struct v4l2_ctrl_handler ctrls;
+
+ bool streaming;
+
+ int pix_clock;
+
+ struct v4l2_mbus_framefmt format; /* height and width always the
same as
in crop */
+ struct v4l2_rect crop;
+ struct v4l2_fract frame_interval;
+
+ struct v4l2_ctrl *hflip, *vflip, *gain, *exposure;
+};
+
+static unsigned long mt9m032_row_time(struct mt9m032 *sensor, int width)
+{
+ int effective_width;
+ u64 ns;
+ effective_width = width + 716; /* emperical value */
Where does it come from ?
+ ns = 10ll * effective_width;
+ do_div(ns, sensor-pix_clock);
Do you have high enough clock frequencies that you would loose precision by
dividing 1e9 by the clock first, and the multiplying it by the row length ? If
so I would use div_u64().
+ dev_dbg(to_dev(sensor), MT9M032 line time: %llu ns\n, ns);
+ return ns;
+}
+
+static int mt9m032_update_timing(struct mt9m032 *sensor,
+ const struct v4l2_fract *interval,
+ const struct v4l2_rect *crop)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sensor-subdev);
+ u64 ns = 10; /* 1 sec */
+ unsigned long row_time;
+ int additional_blanking_rows;
+ int min_blank;
+
+ if (!interval)
+
Another New Member Makes $7,500 In 1 WEEK!
Hello, Yes It is True!!! Would you like a little proof that this business works? We show you our automated, turnkey, never chase another lead system. One new member just received $7,500 using this simple formula. $7,500 in just one week! Imagine how much you can earn in a month. All I did was follow the simple formula he said! http://www.dailycashatm.com With this system I DO NOT chase anybody and you won't have to either... Call me with any questions. Sincerely, Tom VanBuren The Work At Home Expert 363 Harbor Ct Holland,MI 49424 To be removed just reply with REMOVE -- 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: [GIT PATCHES FOR 2.6.38] Compile error fix
On Tuesday 18 January 2011 21:03:49 Hans Verkuil wrote: Hi Mauro, That beautiful 'OK' from the daily build disappeared again. This should bring it back :-) Regards, Hans The following changes since commit fd4564a8c4f23b5ea6526180898ca2aedda2444e: Jarod Wilson (1): [media] staging/lirc: fix mem leaks and ptr err usage are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git cxd2099 I've already posted that fix here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg27186.html https://patchwork.kernel.org/patch/485781/ CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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] [media] v4l: soc-camera: add enum-frame-size ioctl
add vidioc_enum_framesizes implementation
Signed-off-by: Qing Xu qi...@marvell.com
---
drivers/media/video/soc_camera.c | 34 ++
include/media/soc_camera.h |1 +
include/media/v4l2-subdev.h |2 ++
3 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 052bd6d..5e0aa9e 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -145,6 +145,15 @@ static int soc_camera_s_std(struct file *file, void *priv,
v4l2_std_id *a)
return v4l2_subdev_call(sd, core, s_std, *a);
}
+static int soc_camera_enum_fsizes(struct file *file, void *fh,
+struct v4l2_frmsizeenum *fsize)
+{
+ struct soc_camera_device *icd = file-private_data;
+ struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+
+ return ici-ops-enum_fsizes(icd, fsize);
+}
+
static int soc_camera_reqbufs(struct file *file, void *priv,
struct v4l2_requestbuffers *p)
{
@@ -1160,6 +1169,28 @@ static int default_s_parm(struct soc_camera_device *icd,
return v4l2_subdev_call(sd, video, s_parm, parm);
}
+static int default_enum_fsizes(struct soc_camera_device *icd,
+ struct v4l2_frmsizeenum *fsize)
+{
+ int ret;
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ const struct soc_camera_format_xlate *xlate;
+ __u32 pixfmt = fsize-pixel_format;
+ struct v4l2_frmsizeenum *fsize_mbus = fsize;
+
+ xlate = soc_camera_xlate_by_fourcc(icd, pixfmt);
+ if (!xlate)
+ return -EINVAL;
+ /* map xlate-code to pixel_format, sensor only handle xlate-code*/
+ fsize_mbus-pixel_format = xlate-code;
+
+ ret = v4l2_subdev_call(sd, video, enum_mbus_fsizes, fsize_mbus);
+ if (ret 0)
+ return ret;
+
+ return 0;
+}
+
static void soc_camera_device_init(struct device *dev, void *pdata)
{
dev-platform_data = pdata;
@@ -1195,6 +1226,8 @@ int soc_camera_host_register(struct soc_camera_host *ici)
ici-ops-set_parm = default_s_parm;
if (!ici-ops-get_parm)
ici-ops-get_parm = default_g_parm;
+ if (!ici-ops-enum_fsizes)
+ ici-ops-enum_fsizes = default_enum_fsizes;
mutex_lock(list_lock);
list_for_each_entry(ix, hosts, list) {
@@ -1302,6 +1335,7 @@ static const struct v4l2_ioctl_ops soc_camera_ioctl_ops =
{
.vidioc_g_input = soc_camera_g_input,
.vidioc_s_input = soc_camera_s_input,
.vidioc_s_std= soc_camera_s_std,
+ .vidioc_enum_framesizes = soc_camera_enum_fsizes,
.vidioc_reqbufs = soc_camera_reqbufs,
.vidioc_try_fmt_vid_cap = soc_camera_try_fmt_vid_cap,
.vidioc_querybuf = soc_camera_querybuf,
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 86e3631..6e4800c 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -85,6 +85,7 @@ struct soc_camera_host_ops {
int (*set_ctrl)(struct soc_camera_device *, struct v4l2_control *);
int (*get_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
int (*set_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
+ int (*enum_fsizes)(struct soc_camera_device *, struct v4l2_frmsizeenum
*);
unsigned int (*poll)(struct file *, poll_table *);
const struct v4l2_queryctrl *controls;
int num_controls;
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index b0316a7..0d482c9 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -275,6 +275,8 @@ struct v4l2_subdev_video_ops {
struct v4l2_dv_timings *timings);
int (*enum_mbus_fmt)(struct v4l2_subdev *sd, unsigned int index,
enum v4l2_mbus_pixelcode *code);
+ int (*enum_mbus_fsizes)(struct v4l2_subdev *sd,
+struct v4l2_frmsizeenum *fsize);
int (*g_mbus_fmt)(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *fmt);
int (*try_mbus_fmt)(struct v4l2_subdev *sd,
--
1.6.3.3
--
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] [media] v4l: soc-camera: add enum-frame-size ioctl
Hi Guennadi,
Thanks for reviewing my patch! I update it again following your suggestion,
please take your time to review it again, Thanks a lot!
-Qing
Email: qi...@marvell.com
Application Processor Systems Engineering,
Marvell Technology Group Ltd.
-Original Message-
From: Qing Xu [mailto:qi...@marvell.com]
Sent: 2011年1月19日 10:37
To: g.liakhovet...@gmx.de
Cc: linux-media@vger.kernel.org; Qing Xu
Subject: [PATCH] [media] v4l: soc-camera: add enum-frame-size ioctl
add vidioc_enum_framesizes implementation
Signed-off-by: Qing Xu qi...@marvell.com
---
drivers/media/video/soc_camera.c | 34 ++
include/media/soc_camera.h |1 +
include/media/v4l2-subdev.h |2 ++
3 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 052bd6d..5e0aa9e 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -145,6 +145,15 @@ static int soc_camera_s_std(struct file *file, void *priv,
v4l2_std_id *a)
return v4l2_subdev_call(sd, core, s_std, *a);
}
+static int soc_camera_enum_fsizes(struct file *file, void *fh,
+struct v4l2_frmsizeenum *fsize)
+{
+ struct soc_camera_device *icd = file-private_data;
+ struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+
+ return ici-ops-enum_fsizes(icd, fsize);
+}
+
static int soc_camera_reqbufs(struct file *file, void *priv,
struct v4l2_requestbuffers *p)
{
@@ -1160,6 +1169,28 @@ static int default_s_parm(struct soc_camera_device *icd,
return v4l2_subdev_call(sd, video, s_parm, parm);
}
+static int default_enum_fsizes(struct soc_camera_device *icd,
+ struct v4l2_frmsizeenum *fsize)
+{
+ int ret;
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ const struct soc_camera_format_xlate *xlate;
+ __u32 pixfmt = fsize-pixel_format;
+ struct v4l2_frmsizeenum *fsize_mbus = fsize;
+
+ xlate = soc_camera_xlate_by_fourcc(icd, pixfmt);
+ if (!xlate)
+ return -EINVAL;
+ /* map xlate-code to pixel_format, sensor only handle xlate-code*/
+ fsize_mbus-pixel_format = xlate-code;
+
+ ret = v4l2_subdev_call(sd, video, enum_mbus_fsizes, fsize_mbus);
+ if (ret 0)
+ return ret;
+
+ return 0;
+}
+
static void soc_camera_device_init(struct device *dev, void *pdata)
{
dev-platform_data = pdata;
@@ -1195,6 +1226,8 @@ int soc_camera_host_register(struct soc_camera_host *ici)
ici-ops-set_parm = default_s_parm;
if (!ici-ops-get_parm)
ici-ops-get_parm = default_g_parm;
+ if (!ici-ops-enum_fsizes)
+ ici-ops-enum_fsizes = default_enum_fsizes;
mutex_lock(list_lock);
list_for_each_entry(ix, hosts, list) {
@@ -1302,6 +1335,7 @@ static const struct v4l2_ioctl_ops soc_camera_ioctl_ops =
{
.vidioc_g_input = soc_camera_g_input,
.vidioc_s_input = soc_camera_s_input,
.vidioc_s_std= soc_camera_s_std,
+ .vidioc_enum_framesizes = soc_camera_enum_fsizes,
.vidioc_reqbufs = soc_camera_reqbufs,
.vidioc_try_fmt_vid_cap = soc_camera_try_fmt_vid_cap,
.vidioc_querybuf = soc_camera_querybuf,
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 86e3631..6e4800c 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -85,6 +85,7 @@ struct soc_camera_host_ops {
int (*set_ctrl)(struct soc_camera_device *, struct v4l2_control *);
int (*get_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
int (*set_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
+ int (*enum_fsizes)(struct soc_camera_device *, struct v4l2_frmsizeenum
*);
unsigned int (*poll)(struct file *, poll_table *);
const struct v4l2_queryctrl *controls;
int num_controls;
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index b0316a7..0d482c9 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -275,6 +275,8 @@ struct v4l2_subdev_video_ops {
struct v4l2_dv_timings *timings);
int (*enum_mbus_fmt)(struct v4l2_subdev *sd, unsigned int index,
enum v4l2_mbus_pixelcode *code);
+ int (*enum_mbus_fsizes)(struct v4l2_subdev *sd,
+struct v4l2_frmsizeenum *fsize);
int (*g_mbus_fmt)(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *fmt);
int (*try_mbus_fmt)(struct v4l2_subdev *sd,
--
1.6.3.3
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{���bj)��骅w* jg�报 �茛j/�赇z罐���2���ㄨ���)摺�a囤�� �G���h��j:+v���w��佶
RE: soc-camera jpeg support?
Sorry, which solution you would like me to implement?
(1) is to add SOC_MBUS_PACKING_VARIABLE define and add error code in
soc_mbus_bytes_per_line(),
and (2) is to implement int (*try_fmt)(struct v4l2_subdev *sd, struct
v4l2_format *fmt); in subdev, directly get V4L2_PIX_FMT_JPEG info from host
driver.
-Qing
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: 2011年1月19日 1:31
To: Qing Xu
Cc: Laurent Pinchart; Linux Media Mailing List
Subject: RE: soc-camera jpeg support?
Thanks for the code! With it at hand it is going to be easier to
understand and evaluate changes, that you propose to the generic modules.
On Mon, 17 Jan 2011, Qing Xu wrote:
Hi, Guennadi,
Oh, yes, I agree with you, you are right, it is really not that simple,
JPEG is always a headache,:(, as it is quite different from original
yuv/rgb format, it has neither fixed bits-per-sample, nor fixed
packing/bytes-per-line/per-frame, so when coding, I just hack value of
.bits_per_sample and .packing, in fact, you will see in our host driver,
if we find it is JPEG, will ignore bytes-per-line value, for example, in
pxa955_videobuf_prepare(), for jpeg, we always allocate fixed buffer
size for it (or, a better method is to allocate buffer size =
width*height/jpeg-compress-ratio).
I have 2 ideas:
1) Do you think it is reasonable to add a not-fixed define into
soc_mbus_packing:
enum soc_mbus_packing {
SOC_MBUS_PACKING_NOT_FIXED,
...
};
And then, .bits_per_sample = 0, /* indicate that sample bits is
not-fixed*/
And, in function:
s32 soc_mbus_bytes_per_line(u32 width, const struct soc_mbus_pixelfmt *mf)
{
switch (mf-packing) {
case SOC_MBUS_PACKING_NOT_FIXED:
return 0;
case SOC_MBUS_PACKING_NONE:
return width * mf-bits_per_sample / 8;
...
}
return -EINVAL;
}
2) Or, an workaround in sensor(ov5642.c), is to implement:
int (*try_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
use the member (fmt-pix-pixelformat == V4L2_PIX_FMT_JPEG) to find out
if it is jpeg. And in host driver, it calls try_fmt() into sensor. In
this way, no need to change soc-camera common code, but I feel that it
goes against with your xxx_mbus_xxx design purpose, right?
I actually prefer this one, but with an addition of V4L2_MBUS_FMT_JPEG_1X8
as per your additional üatch, but, please, also add a new packing, e.g.,
SOC_MBUS_PACKING_COMPRESSED (or SOC_MBUS_PACKING_VARIABLE?). So, that we
can cleanly translate between V4L2_MBUS_FMT_JPEG_1X8 and
V4L2_PIX_FMT_JPEG, but host drivers, that want to support this, will have
to know to calculate frame sizes in some special way, not just aborting,
if soc_mbus_bytes_per_line() returned an error. We might also consider
returning a different error code for this case, e.g., we could change the
general error case to return -ENOENT, and use -EINVAL for cases like JPEG,
where data is valid, but no valid calculation is possible.
Thanks
Guennadi
What do you think?
Please check the attachment, it is our host camera controller driver and
sensor.
Thanks a lot!
-Qing
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: 2011Äê1ÔÂ18ÈÕ 1:39
To: Qing Xu
Cc: Laurent Pinchart; Linux Media Mailing List
Subject: Re: soc-camera jpeg support?
On Mon, 17 Jan 2011, Qing Xu wrote:
Hi,
Many of our sensors support directly outputting JPEG data to camera
controller, do you feel it's reasonable to add jpeg support into
soc-camera? As it seems that there is no define in v4l2-mediabus.h which
is suitable for our case.
In principle I have nothing against this, but, I'm afraid, it is not quite
that simple. I haven't worked with such sensors myself, but, AFAIU, the
JPEG image format doesn't have fixed bytes-per-line and bytes-per-frame
values. If you add it like you propose, this would mean, that it just
delivers normal 8 bits per pixel images. OTOH, soc_mbus_bytes_per_line()
would just return -EINVAL for your JPEG format, so, unsupporting drivers
would just error out, which is not all that bad. When the first driver
decides to support JPEG, they will have to handle that error. But maybe
we'll want to return a special error code for it.
But, in fact, that is in a way my problem with your patches: you propose
extensions to generic code without showing how this is going to be used in
specific drivers. Could you show us your host driver, please? I don't
think this is still the pxa27x driver, is it?
Thanks
Guennadi
Such as:
--- a/drivers/media/video/soc_mediabus.c
+++ b/drivers/media/video/soc_mediabus.c
@@ -130,6 +130,13 @@ static const struct soc_mbus_pixelfmt mbus_fmt[] = {
.packing= SOC_MBUS_PACKING_2X8_PADLO,
.order = SOC_MBUS_ORDER_BE,
},
+ [MBUS_IDX(JPEG_1X8)] =
Re: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Jan 16, 2011, at 10:29 PM, Andy Walls wrote: On Sun, 2011-01-16 at 14:20 -0500, Andy Walls wrote: Mauro, Please pull the one ir-kbd-i2c change and multiple lirc_zilog changes for 2.6.38. The one ir-kbd-i2c change is to put back a case to have ir-kbd-i2c set defaults for I2C client address 0x71. I know I was the one who recommend that ir-kbd-i2c not do this, but I discovered pvrusb2 and bttv rely on it for the moment - Mea culpa. The lirc_zilog changes are tested to work with both Tx and Rx with an HVR-1600. I don't want to continue much further on lirc_zilog changes, unitl a few things happen: 1. I have developed, and have had tested, a patch for the pvrusb2 driver to allow the in kernel lirc_zilog to bind to a Z8 on a pvrusb2 supported device. Mauro, I have developed a patch for pvrusb2 and Mike Isely provided his Ack. I have added it to my z8 branch and this pull request. I've finally got around to trying it out with the HVR-1950 I've got here, and it does do the trick for ir-kbd-i2c (albeit I never see proper key repeats, only alternating press/release key events). Not working with lirc_zilog yet, it fails to load, due to an -EIO ret to one of the i2c_master_send() calls in lirc_zilog during probe of the TX side. Haven't looked into it any more than that yet. 2. Jarrod finishes his changes related to the Z8 chip for hdpvr and they are pulled into media_tree.git branch. They're in now. Still need to tweak the ir-kbd-i2c usage by hdpvr a bit, but at least I'm close to having other hardware to compare and contrast with, behavior-wise. 3. I hear from Jean, or whomever really cares about ir-kbd-i2c, if adding some new fields for struct IR_i2c_init_data is acceptable. Specifically, I'd like to add a transceiver_lock mutex, a transceiver reset callback, and a data pointer for that reset callback. (Only lirc_zilog would use the reset callback and data pointer.) 4. I find spare time ever again. Ha, I feel your pain... ;) -- Jarod Wilson ja...@wilsonet.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
Re: [PATCH] v4l: Add driver for Micron MT9M032 camera sensor
On Wednesday, January 19, 2011 00:50:35 Laurent Pinchart wrote:
Hi Hans and Martin,
On Wednesday 19 January 2011 00:05:10 Hans Verkuil wrote:
On Tuesday, January 18, 2011 23:18:42 Martin Hostettler wrote:
[snip]
+ return mt9m032_write_reg(client, MT9M032_VBLANK,
additional_blanking_rows);
I've found it easier to do the v4l2_subdev to i2c_client conversion at the
lowest level: the read/write register functions. That way the conversion is
done at only a few places, rather than at every place these read/write reg
functions are called. Just my opinion, though.
I agree with this.
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+static long mt9m032_ioctl(struct v4l2_subdev *sd, unsigned int cmd, void
*arg) +{
+ if (cmd == VIDIOC_DBG_G_REGISTER || cmd == VIDIOC_DBG_S_REGISTER) {
+ struct v4l2_dbg_register *p = arg;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ if (cmd == VIDIOC_DBG_G_REGISTER)
+ return v4l2_subdev_call(sd, core, g_register, p);
+ else
+ return v4l2_subdev_call(sd, core, s_register, p);
+ } else {
+ return -ENOIOCTLCMD;
+ }
+}
Huh? Ah, I get it. This is for when the user uses the subdev's device node
directly. This is not good, the v4l2 framework should do translate this to
g/s_register.
Agreed.
The same should be done for g_chip_ident, I guess.
I don't think we need g_chip_ident for subdev nodes, do we ?
Why not? It makes the use of v4l2-dbg a bit easier if it is there. If you
provide g/s_register, then you should provide this one as well.
I though of another one that should be handled in the framework:
VIDIOC_LOG_STATUS.
That definitely should be handled as well.
Regards,
Hans
+#endif
--
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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
video_device - v4l2_devnode rename
Hi Mauro, I saw that 2.6.38-rc1 was released. I also noticed that not all the patches that are in the for_2.6.38-rc1 branch are in 2.6.38-rc1. We want to rename video_device to v4l2_devnode. So let me know when I can finalize my patches and, most importantly, against which branch. My current tree: http://git.linuxtv.org/hverkuil/media_tree.git?a=shortlog;h=refs/heads/devnode2 tracks for_2.6.38-rc1 and should apply cleanly at the moment. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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
