Re: [beagleboard] [PATCH v6 2/2] Add support for mt9p031 sensor in Beagleboard XM.
Hi Koen, On 1 June 2011 20:08, Koen Kooi k...@beagleboard.org wrote: Op 1 jun 2011, om 17:36 heeft Javier Martin het volgende geschreven: New version and vdd_io flags have been added. A subtle change now prevents camera from being registered in the wrong platform. I get a decent picture now with the following: media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], OMAP3 ISP CCDC:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]' yavta-nc --stdout -f SGRBG8 -s 320x240 -n 4 --capture=1 --skip 3 -F $(media-ctl -e OMAP3 ISP CCDC output) | mplayer-bayer - -demuxer rawvideo -rawvideo w=320:h=240:format=ba81:size=76800 -vo fbdev2 -vf ba81 720p also seems to work. It is really, really dark though. Is this due to missing controls or due to the laneshifting? I suspect it is due to the patched mplayer. I know this because I have enabled some custom patterns in the sensor, thus generating pure red, blue and green pictures and they didn't seem so when played through mplayer-bayer. You could try the same if you want. Just to confirm. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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: [RFC/PATCH v2] v4l: add control definitions for codec devices.
Hi, Thank you for your nice work. Here are my some comments. -Original Message- From: Kamil Debski [mailto:k.deb...@samsung.com] Sent: Tuesday, May 31, 2011 6:08 PM Cc: m.szyprow...@samsung.com; kyungmin.p...@samsung.com; k.deb...@samsung.com; jaeryul...@samsung.com; hverk...@xs4all.nl; laurent.pinch...@ideasonboard.com; jtp.p...@samsung.com Subject: [RFC/PATCH v2] v4l: add control definitions for codec devices. Hi, This is a second version of the patch that adds controls for the codec family of devices. I have implemented the suggestions I got from Hans Verkuil on the #v4l channel. Change log: - rename V4L2_CID_MIN_REQ_BUFS_(CAP/OUT) to V4L2_CID_MIN_BUFFERS_FOR_(CAPTURE/OUTPUT) - use existing controls for GOP size, number of frames and GOP closure - remove frame rate controls (in favour of the S_PARM call) - split level into separate controls for MPEG4 and H264 I would welcome further comments. Best regards, Kamil Debski Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Documentation/DocBook/v4l/controls.xml | 733 include/linux/videodev2.h | 147 +++ 2 files changed, 880 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index 6880798..7c2df42 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -325,6 +325,22 @@ minimum value disables backlight compensation./entry constantV4L2_CID_ILLUMINATORS_2/constant + 1)./entry /row row + entryconstantV4L2_CID_MIN_BUFFERS_FOR_CAPTURE/constant/entry + entryinteger/entry + entryThis is a read only control that can read by the application +and used as a hint to determine the number of CAPTURE buffer to pass to REQBUFS. +The value is the minimum number of CAPTURE buffer that it necessary for hardware +to work./entry + /row + row + entryconstantV4L2_CID_MIN_BUFFERSS_FOR_OUTPUT/constant/entry + entryinteger/entry + entryThis is a read only control that can read by the application +and used as a hint to determine the number of OUTPUT buffer to pass to REQBUFS. +The value is the minimum number of OUTPUT buffer that it necessary for hardware +to work./entry + /row + row entryconstantV4L2_CID_PRIVATE_BASE/constant/entry entry/entry entryID of the first custom (driver specific) control. @@ -1409,6 +1425,723 @@ of the video. The supplied 32-bit integer is interpreted as follows (bit /tbody /entrytbl /row + + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrIf enabled the decoder expects a single slice in one buffer, otherwise +the decoder expects a single frame in one input buffer./entry + /row + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_VUI_AR_ENABLE/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrEnable writing aspect ratio in the Video Usability Information./entry + /row + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_VUI_AR_IDC/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrVUI aspect ratio IDC for H.264 encoding. The value is defined in VUI Table +E-1 in the standard. + /entry + /row + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_EXT_SAR_WIDTH/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrExtended sample aspect ratio width for H.264 VUI encoding./entry + /row + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_EXT_SAR_HEIGHT/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrExtended sample aspect ratio height for H.264 VUI encoding./entry + /row + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_LEVEL/constantnbsp;/entry + entryenumnbsp;v4l2_mpeg_level/entry + /row + rowentry spanname=descrThe level information for stream. +Possible values are:/entry + /row + row + entrytbl spanname=descr cols=2 + tbody valign=top + row +
[PATCH] MAINTAINERS: Add videobuf2 maintainers
Add maintainers for the videobuf2 V4L2 driver framework. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- MAINTAINERS |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 29801f7..63be58b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6720,6 +6720,15 @@ S: Maintained F: Documentation/filesystems/vfat.txt F: fs/fat/ +VIDEOBUF2 FRAMEWORK +M: Pawel Osciak pa...@osciak.com +M: Marek Szyprowski m.szyprow...@samsung.com +M: Kyungmin Park kyungmin.p...@samsung.com +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/media/video/videobuf2-* +F: include/media/videobuf2-* + VIRTIO CONSOLE DRIVER M: Amit Shah amit.s...@redhat.com L: virtualizat...@lists.linux-foundation.org -- 1.7.1.569.g6f426 -- 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 v6 1/2] Add driver for Aptina (Micron) mt9p031 sensor.
No technical review this time. Relying fully on Laurent and others to take care of that, just a couple of cosmetic points, which even checkpatch.pl failed to warn about:( On Wed, 1 Jun 2011, Javier Martin wrote: Clock frequency of 57MHz used in previous version was wrong since when VDD_IO is 1.8V it can only support 48MHz. Two new platform flags have been added: - vdd_io: indicates whether the chip is powered with 1.8 or 2.8 VDD_IO. So that it can use the maximum allowed frequency. - version: monochrome and color versions of the chip have exactly the same ID, so the only way to select one of them is through platform data. Internal PLL is now used to generate PIXCLK depending on VDD_IO. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/mt9p031.c | 763 + include/media/mt9p031.h | 23 ++ 4 files changed, 794 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mt9p031.c create mode 100644 include/media/mt9p031.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 00f51dd..cb87e35 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -329,6 +329,13 @@ config VIDEO_OV7670 OV7670 VGA camera. It currently only works with the M88ALP01 controller. +config VIDEO_MT9P031 + tristate Aptina MT9P031 support + depends on I2C VIDEO_V4L2 + ---help--- +This is a Video4Linux2 sensor-level driver for the Aptina +(Micron) mt9p031 5 Mpixel camera. + Please, use TABs, not spaces config VIDEO_MT9V011 tristate Micron mt9v011 sensor support depends on I2C VIDEO_V4L2 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index ace5d8b..912b29b 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -65,6 +65,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_MT9P031) += mt9p031.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_SR030PC30)+= sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30) += noon010pc30.o diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c new file mode 100644 index 000..cd830b1 --- /dev/null +++ b/drivers/media/video/mt9p031.c @@ -0,0 +1,763 @@ +/* + * Driver for MT9P031 CMOS Image Sensor from Aptina + * + * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com + * + * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de + * + * Based on the MT9V032 driver and Bastian Hecht's code. + * + * 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. + */ + +#include linux/delay.h +#include linux/device.h +#include linux/i2c.h +#include linux/log2.h +#include linux/pm.h +#include linux/slab.h +#include media/v4l2-subdev.h +#include linux/videodev2.h + +#include media/mt9p031.h +#include media/v4l2-chip-ident.h +#include media/v4l2-subdev.h +#include media/v4l2-device.h + +#define MT9P031_EXTCLK_FREQ 2000 + +#define MT9P031_CHIP_VERSION 0x00 +#define MT9P031_CHIP_VERSION_VALUE 0x1801 +#define MT9P031_ROW_START0x01 +#define MT9P031_ROW_START_MIN 1 +#define MT9P031_ROW_START_MAX 2004 +#define MT9P031_ROW_START_DEF 54 +#define MT9P031_COLUMN_START 0x02 +#define MT9P031_COLUMN_START_MIN1 +#define MT9P031_COLUMN_START_MAX2750 +#define MT9P031_COLUMN_START_DEF16 +#define MT9P031_WINDOW_HEIGHT0x03 +#define MT9P031_WINDOW_HEIGHT_MIN 2 +#define MT9P031_WINDOW_HEIGHT_MAX 2003 +#define MT9P031_WINDOW_HEIGHT_DEF 2003 +#define MT9P031_WINDOW_WIDTH 0x04 +#define MT9P031_WINDOW_WIDTH_MIN18 +#define MT9P031_WINDOW_WIDTH_MAX2751 +#define MT9P031_WINDOW_WIDTH_DEF2751 +#define MT9P031_H_BLANKING 0x05 +#define MT9P031_H_BLANKING_VALUE0 +#define MT9P031_V_BLANKING 0x06 +#define MT9P031_V_BLANKING_VALUE25 +#define MT9P031_OUTPUT_CONTROL 0x07 +#define MT9P031_OUTPUT_CONTROL_CEN 2 +#define MT9P031_OUTPUT_CONTROL_SYN 1 +#define MT9P031_SHUTTER_WIDTH_UPPER 0x08 +#define MT9P031_SHUTTER_WIDTH0x09
Re: [PATCH V2] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
On Wed, 1 Jun 2011 21:16:45 +0800 Kassey Lee y...@marvell.com wrote: This driver exports a video device node per each CCIC (CMOS Camera Interface Controller) device contained in Marvell Mobile PXA910 SoC The driver is based on soc-camera + videobuf2 frame work, and only USERPTR is supported. This device looks awfully similar to the Cafe controller; you must certainly have known that, since some of the code in your driver is clearly copied (without attribution) from cafe_ccic.c. As it happens, I've just written a driver for the Armada 610 SoC found in the OLPC 1.75 system; I was planning to post it as early as next week. I took a different approach, though: rather than duplicating the Cafe code, I split that driver into core and platform parts, then added a new platform piece for the Armada 610. I do believe that is a better way of doing things. That said, your driver has useful stuff that mine doesn't - MIPI support, for example. I'm traveling, but will be back next week. I'll send out my work after that; then I would really like to find a way to make all these pieces work together with a common core for cafe-derived controllers. Make sense? Thanks, jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 - resend] Fix the derot zig-zag to work with TT-USB2.0 TechnoTrend.
Hello Hans Petter,
I haven't tested your patch yet, but looking at the source I see some
problems.
What does your patch fix and how?
If you have problem locking channels, try my locking patch:
https://patchwork.kernel.org/patch/753382/
On each step (timing, carrier, data) you reset the derot:
stb0899_set_derot(state, 0);
Why?
Afaik you destroy already locked frequencies, which slows
down the locking.
Than you do 8 loops:
for (index = 0; index 8; index++) {
Why?
All checks already contains some delays, if the delays are too
short, you should fix this delays.
Johns
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
hi, Jonathan: yes, you are right, this driver uses most of the low level code from cafe-ccic.c. I am so sorry to miss the your email and refer info from cafe-ccic.c in my driver, really appreciate your work. the point that I write mv_camera.c is to base the soc_camera + vidieobuf2, other than manage the buffer by our-self which is done in cafe-ccic.c. I am OK to wait for your work on Armada 610, is this based on soc_camera + videobuf2 ? let's make it a more graceful driver. thanks On Thu, Jun 2, 2011 at 5:24 PM, Jonathan Corbet cor...@lwn.net wrote: On Wed, 1 Jun 2011 21:16:45 +0800 Kassey Lee y...@marvell.com wrote: This driver exports a video device node per each CCIC (CMOS Camera Interface Controller) device contained in Marvell Mobile PXA910 SoC The driver is based on soc-camera + videobuf2 frame work, and only USERPTR is supported. This device looks awfully similar to the Cafe controller; you must certainly have known that, since some of the code in your driver is clearly copied (without attribution) from cafe_ccic.c. As it happens, I've just written a driver for the Armada 610 SoC found in the OLPC 1.75 system; I was planning to post it as early as next week. I took a different approach, though: rather than duplicating the Cafe code, I split that driver into core and platform parts, then added a new platform piece for the Armada 610. I do believe that is a better way of doing things. That said, your driver has useful stuff that mine doesn't - MIPI support, for example. I'm traveling, but will be back next week. I'll send out my work after that; then I would really like to find a way to make all these pieces work together with a common core for cafe-derived controllers. Make sense? Thanks, jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
On Thu, 2 Jun 2011, Jonathan Corbet wrote: On Wed, 1 Jun 2011 21:16:45 +0800 Kassey Lee y...@marvell.com wrote: This driver exports a video device node per each CCIC (CMOS Camera Interface Controller) device contained in Marvell Mobile PXA910 SoC The driver is based on soc-camera + videobuf2 frame work, and only USERPTR is supported. This device looks awfully similar to the Cafe controller; you must certainly have known that, since some of the code in your driver is clearly copied (without attribution) from cafe_ccic.c. Yes, I noticed this, as I saw the cafe_ccic header being included in this driver. As it happens, I've just written a driver for the Armada 610 SoC found in the OLPC 1.75 system; I was planning to post it as early as next week. I took a different approach, though: rather than duplicating the Cafe code, I split that driver into core and platform parts, then added a new platform piece for the Armada 610. I do believe that is a better way of doing things. That said, your driver has useful stuff that mine doesn't - MIPI support, for example. I'm traveling, but will be back next week. I'll send out my work after that; then I would really like to find a way to make all these pieces work together with a common core for cafe-derived controllers. Make sense? This is definitely the right direction! Thanks for your heads-up! Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 - resend] Fix the derot zig-zag to work with TT-USB2.0 TechnoTrend.
On Thursday 02 June 2011 11:46:15 Lutz Sammer wrote:
Hello Hans Petter,
Hi,
I haven't tested your patch yet, but looking at the source I see some
problems.
What does your patch fix and how?
It switches from software derot to hardware derot, by writing zero to the
derot register.
If you have problem locking channels, try my locking patch:
https://patchwork.kernel.org/patch/753382/
On each step (timing, carrier, data) you reset the derot:
stb0899_set_derot(state, 0);
Why?
I have no good reason. It just works.
Afaik you destroy already locked frequencies, which slows
down the locking.
Than you do 8 loops:
for (index = 0; index 8; index++) {
Why?
All checks already contains some delays, if the delays are too
short, you should fix this delays.
I can test patches regarding channel locking. The initial problem was the the
stb0899 driver would not tune any channels.
--HPS
--
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 v6 1/2] Add driver for Aptina (Micron) mt9p031 sensor.
OK Guennadi, I'll fix those cosmetics issues in my next version where I will add VFLIP and HFLIP control support (which I removed previously to make the code less complex). Now we talk about controls I have a question regarding controls defined in video subdevices like mt9p031 or mt9v032: What device node should I use to set these controls through an ioctl() ? For instance, with mt9p031 + Beagleboard xM we have: ./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' ./media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], OMAP3 ISP CCDC:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]' ./yavta --stdout -f SGRBG8 -s 320x240 -n 4 --capture=100 --skip 3 -F `./media-ctl -e OMAP3 ISP CCDC output` | nc 192.168.0.42 3000 Where root@beagleboard:~# ./media-ctl -e OMAP3 ISP CCDC output /dev/video2 However, if I try to set sensor controls using /dev/video2 I get an error (invalid argument). -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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
[PATCH 0/7] s5p-fimc driver fixes for 3.0
Hello, the following are a few bugfix patches for s5p-fimc driver. Except the kernel-doc comments corrections, debug trace cleanup and the copyright update they fix the buffer allocation issue and possible memory leak on error path. drivers/media/video/s5p-fimc/fimc-capture.c | 21 ++ drivers/media/video/s5p-fimc/fimc-core.c| 28 +++-- drivers/media/video/s5p-fimc/fimc-core.h| 29 -- 3 files changed, 24 insertions(+), 54 deletions(-) Regards, -- Sylwester Nawrocki 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
[PATCH 3/7] s5p-fimc: Fix data structures documentation and cleanup debug trace
Correct inconsistencies in data structures' documentation.
Remove meaningless debug traces.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c |9 -
drivers/media/video/s5p-fimc/fimc-core.c|6 --
drivers/media/video/s5p-fimc/fimc-core.h| 25 -
3 files changed, 12 insertions(+), 28 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 7e66455..44fc26f 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -262,12 +262,7 @@ static unsigned int get_plane_size(struct fimc_frame *fr,
unsigned int plane)
{
if (!fr || plane = fr-fmt-memplanes)
return 0;
-
- dbg(%s: w: %d. h: %d. depth[%d]: %d,
- __func__, fr-width, fr-height, plane, fr-fmt-depth[plane]);
-
return fr-f_width * fr-f_height * fr-fmt-depth[plane] / 8;
-
}
static int queue_setup(struct vb2_queue *vq, unsigned int *num_buffers,
@@ -283,12 +278,8 @@ static int queue_setup(struct vb2_queue *vq, unsigned int
*num_buffers,
*num_planes = fmt-memplanes;
- dbg(%s, buffer count=%d, plane count=%d,
- __func__, *num_buffers, *num_planes);
-
for (i = 0; i fmt-memplanes; i++) {
sizes[i] = get_plane_size(ctx-d_frame, i);
- dbg(plane: %u, plane_size: %lu, i, sizes[i]);
allocators[i] = ctx-fimc_dev-alloc_ctx;
}
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index f1c7119..c427edd 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -231,11 +231,7 @@ static int fimc_get_scaler_factor(u32 src, u32 tar, u32
*ratio, u32 *shift)
return 0;
}
}
-
*shift = 0, *ratio = 1;
-
- dbg(s: %d, t: %d, shift: %d, ratio: %d,
- src, tar, *shift, *ratio);
return 0;
}
@@ -267,10 +263,8 @@ int fimc_set_scaler_info(struct fimc_ctx *ctx)
err(invalid source size: %d x %d, sx, sy);
return -EINVAL;
}
-
sc-real_width = sx;
sc-real_height = sy;
- dbg(sx= %d, sy= %d, tx= %d, ty= %d, sx, sy, tx, ty);
ret = fimc_get_scaler_factor(sx, tx, sc-pre_hratio, sc-hfactor);
if (ret)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index 3beb1e5..8f0f168 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -135,9 +135,10 @@ enum fimc_color_fmt {
* @name: format description
* @fourcc: the fourcc code for this format, 0 if not applicable
* @color: the corresponding fimc_color_fmt
- * @depth: per plane driver's private 'number of bits per pixel'
* @memplanes: number of physically non-contiguous data planes
* @colplanes: number of physically contiguous data planes
+ * @depth: per plane driver's private 'number of bits per pixel'
+ * @flags: flags indicating which operation mode format applies to
*/
struct fimc_fmt {
enum v4l2_mbus_pixelcode mbus_code;
@@ -171,7 +172,7 @@ struct fimc_dma_offset {
};
/**
- * struct fimc_effect - the configuration data for the Arbitrary image effect
+ * struct fimc_effect - color effect information
* @type: effect type
* @pat_cb:cr value when type is arbitrary
* @pat_cr:cr value when type is arbitrary
@@ -184,7 +185,6 @@ struct fimc_effect {
/**
* struct fimc_scaler - the configuration data for FIMC inetrnal scaler
- *
* @scaleup_h: flag indicating scaling up horizontally
* @scaleup_v: flag indicating scaling up vertically
* @copy_mode: flag indicating transparent DMA transfer (no scaling
@@ -220,7 +220,6 @@ struct fimc_scaler {
/**
* struct fimc_addr - the FIMC physical address set for DMA
- *
* @y: luminance plane physical address
* @cb: Cb plane physical address
* @cr: Cr plane physical address
@@ -234,6 +233,7 @@ struct fimc_addr {
/**
* struct fimc_vid_buffer - the driver's video buffer
* @vb:v4l videobuf buffer
+ * @list: linked list structure for buffer queue
* @paddr: precalculated physical address set
* @index: buffer index for the output DMA engine
*/
@@ -254,11 +254,10 @@ struct fimc_vid_buffer {
* @offs_v:image vertical pixel offset
* @width: image pixel width
* @height:image pixel weight
- * @paddr: image frame buffer physical addresses
- * @buf_cnt: number of buffers depending on a color format
* @payload: image size in bytes (w x h x bpp)
- * @color: color format
+ * @paddr: image frame buffer physical addresses
* @dma_offset:DMA offset in bytes
+ * @fmt: fimc color format pointer
*/
struct fimc_frame {
[PATCH 2/7] s5p-fimc: Fix V4L2_PIX_FMT_RGB565X description
Remove V4L2_MBUS_FMT_RGB565_2X8_BE media code entry as
camera interface supports only packed YUYV formats.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-core.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index dc91a85..f1c7119 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -42,7 +42,6 @@ static struct fimc_fmt fimc_formats[] = {
.color = S5P_FIMC_RGB565,
.memplanes = 1,
.colplanes = 1,
- .mbus_code = V4L2_MBUS_FMT_RGB565_2X8_BE,
.flags = FMT_FLAGS_M2M,
}, {
.name = BGR666,
--
1.7.5.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] s5p-fimc: Remove empty buf_init operation
The buf_init buffer queue operation is optional and
buffer_init() does nothing, remove it.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 44fc26f..6901643 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -286,12 +286,6 @@ static int queue_setup(struct vb2_queue *vq, unsigned int
*num_buffers,
return 0;
}
-static int buffer_init(struct vb2_buffer *vb)
-{
- /* TODO: */
- return 0;
-}
-
static int buffer_prepare(struct vb2_buffer *vb)
{
struct vb2_queue *vq = vb-vb2_queue;
@@ -371,7 +365,6 @@ static struct vb2_ops fimc_capture_qops = {
.queue_setup= queue_setup,
.buf_prepare= buffer_prepare,
.buf_queue = buffer_queue,
- .buf_init = buffer_init,
.wait_prepare = fimc_unlock,
.wait_finish= fimc_lock,
.start_streaming= start_streaming,
--
1.7.5.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/2] Add driver for Aptina (Micron) mt9p031 sensor.
On Thu, 2 Jun 2011, javier Martin wrote: OK Guennadi, I'll fix those cosmetics issues in my next version where I will add VFLIP and HFLIP control support (which I removed previously to make the code less complex). Please, don't. Let's first get the simple version of your driver in the mainline, then it can be extended. Just, please, make sure to address all remaining issues without changing anything else:) Thanks Guennadi Now we talk about controls I have a question regarding controls defined in video subdevices like mt9p031 or mt9v032: What device node should I use to set these controls through an ioctl() ? For instance, with mt9p031 + Beagleboard xM we have: ./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' ./media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], OMAP3 ISP CCDC:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]' ./yavta --stdout -f SGRBG8 -s 320x240 -n 4 --capture=100 --skip 3 -F `./media-ctl -e OMAP3 ISP CCDC output` | nc 192.168.0.42 3000 Where root@beagleboard:~# ./media-ctl -e OMAP3 ISP CCDC output /dev/video2 However, if I try to set sensor controls using /dev/video2 I get an error (invalid argument). -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/2] Add driver for Aptina (Micron) mt9p031 sensor.
On 2 June 2011 12:36, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Thu, 2 Jun 2011, javier Martin wrote: OK Guennadi, I'll fix those cosmetics issues in my next version where I will add VFLIP and HFLIP control support (which I removed previously to make the code less complex). Please, don't. Let's first get the simple version of your driver in the mainline, then it can be extended. Just, please, make sure to address all remaining issues without changing anything else:) Ok, thanks. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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: [linux-dvb] XC4000 patches for kernel 2.6.37.2
2011/5/31 Dmitri Belimov d.beli...@gmail.com: Is it possible make some patches and add support xc4000 into kernel? With my best regards, Dmitry. What needs to happen here is somebody needs to prepare a patch series which contains all the relevant patches, including the SOBs. This is entirely an janitorial task which can be done by anyone and frankly I don't have time for this sort of crap anymore. Any volunteers? All my patches have my SOB attached. I explicitly got Davide's permission to add his SOB to his original patch, but it's not in the HG tree since I got the permission after I committed his change to my repo. I can forward the email with his SOB so the person constructing the tree can add it on (as well as my SOB to preserve the chain of custody). Secondly, we need to build a firmware image which is based off of the *actual* xceive firmware sources, so that we can be confident that all the blobs are from the same firmware revision and so that we can maintain them going forward. I can provide them off-list to someone willing to do this work and testing. Istann_v's firmware image is based off of i2c dumps and extracted by hand from disassembled firmware, which is less than ideal from an ongoing maintenance perspective. And of course it's worth mentioning that the driver itself still needs a ton of cleanup, doesn't meet the coding standards, and wouldn't be accepted upstream in its current state. Somebody will need to do the work to clean up the driver, as well as testing to make sure he/she didn't cause any regressions. In summary, here are the four things that need to happen: 1. Assemble tree with current patches 2. Construct valid firmware image off of current sources 3. Cleanup/coding style 4. Testing Now that we've got a bunch of people who are interested in seeing this upstream, who is going to volunteer to do which items in the above list? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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
SOB for original xc4000 patch
Here is the email thread where Davide Ferri consented to having the SOB added to his original patch. Whoever prepares the patch series should ensure that it has the following chain of SOBs: Signed-off-by: Davide Ferri davidef1...@gmail.com Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com Devin -- Forwarded message -- From: Davide Ferri davidef1...@gmail.com Date: Sun, Mar 21, 2010 at 6:37 PM Subject: Re: Signed-off by for your patch To: Devin Heitmueller dheitmuel...@kernellabs.com I don't know what exactly implies to sign-off that patch, anyway you can of course add my email there if you need to do so. If there's any thing I can do, please tell me. Davide P.s.: Have you investigated the module unload problem when the stick is removed while scanning/watching tv ? Currently I don't have much free time to investigate as I'm writing my bachelor's thesis on this project www.nbee.org On Sun, Mar 21, 2010 at 11:17 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: Hello Davide, I'm trying to get some stuff wrapped up for the 340e merge, and I noticed that I never actually got your signed-off-by for the following patch: http://kernellabs.com/hg/~dheitmueller/pctv-340e-2/rev/9eb9b35cef5a Could you please consent to the following SOB being added to the patch so this can be submitted upstream? Signed-off-by: Davide Ferri davidef1...@gmail.com, Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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] [media] V4L/videobuf2-memops: use pr_debug for debug messages
Em 02-06-2011 02:56, Marek Szyprowski escreveu: Hello, On Thursday, June 02, 2011 3:35 AM Mauro Carvalho Chehab wrote: Hi Kyungmin, Em 01-06-2011 21:50, Kyungmin Park escreveu: Acked-by: Kyungmin Park kyunginn.,p...@samsung.com As this patch is really trivial and makes sense, I've just applied it earlier today. thanks! --- I think it's better to add the videobuf2 maintainer entry for proper person to know the changes. In this case, Marek is missing. If any objection, I will make a patch. No objections from my side. Having the proper driver maintainers written at MAINTAINERS help people when submitting patches to send the patch to the proper driver maintainer. It looks that the patch for MAINTAINERS have been lost. It was initially posted by Pawel some time ago: https://lkml.org/lkml/2011/3/20/82 patchwork.kernel.org is not reliable. I think I'll need to migrate it to something else. I will resend it to linux-media ml. Thanks! I noticed that Pawel's SOB is missed at the proposed patch. Pawel, could you please reply to it with your SOB? 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
[PATCH v7 1/2] Add driver for Aptina (Micron) mt9p031 sensor.
This version fixes some cosmetic issues pointed out by Guennadi. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/mt9p031.c | 763 + include/media/mt9p031.h | 23 ++ 4 files changed, 794 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mt9p031.c create mode 100644 include/media/mt9p031.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 00f51dd..5f851f0 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -329,6 +329,13 @@ config VIDEO_OV7670 OV7670 VGA camera. It currently only works with the M88ALP01 controller. +config VIDEO_MT9P031 + tristate Aptina MT9P031 support + depends on I2C VIDEO_V4L2 + ---help--- + This is a Video4Linux2 sensor-level driver for the Aptina + (Micron) mt9p031 5 Mpixel camera. + config VIDEO_MT9V011 tristate Micron mt9v011 sensor support depends on I2C VIDEO_V4L2 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index ace5d8b..912b29b 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -65,6 +65,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_MT9P031) += mt9p031.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c new file mode 100644 index 000..36c47df --- /dev/null +++ b/drivers/media/video/mt9p031.c @@ -0,0 +1,763 @@ +/* + * Driver for MT9P031 CMOS Image Sensor from Aptina + * + * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com + * + * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de + * + * Based on the MT9V032 driver and Bastian Hecht's code. + * + * 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. + */ + +#include linux/delay.h +#include linux/device.h +#include linux/i2c.h +#include linux/log2.h +#include linux/pm.h +#include linux/slab.h +#include media/v4l2-subdev.h +#include linux/videodev2.h + +#include media/mt9p031.h +#include media/v4l2-chip-ident.h +#include media/v4l2-subdev.h +#include media/v4l2-device.h + +#define MT9P031_EXTCLK_FREQ2000 + +#define MT9P031_CHIP_VERSION 0x00 +#defineMT9P031_CHIP_VERSION_VALUE 0x1801 +#define MT9P031_ROW_START 0x01 +#defineMT9P031_ROW_START_MIN 1 +#defineMT9P031_ROW_START_MAX 2004 +#defineMT9P031_ROW_START_DEF 54 +#define MT9P031_COLUMN_START 0x02 +#defineMT9P031_COLUMN_START_MIN1 +#defineMT9P031_COLUMN_START_MAX2750 +#defineMT9P031_COLUMN_START_DEF16 +#define MT9P031_WINDOW_HEIGHT 0x03 +#defineMT9P031_WINDOW_HEIGHT_MIN 2 +#defineMT9P031_WINDOW_HEIGHT_MAX 2003 +#defineMT9P031_WINDOW_HEIGHT_DEF 2003 +#define MT9P031_WINDOW_WIDTH 0x04 +#defineMT9P031_WINDOW_WIDTH_MIN18 +#defineMT9P031_WINDOW_WIDTH_MAX2751 +#defineMT9P031_WINDOW_WIDTH_DEF2751 +#define MT9P031_H_BLANKING 0x05 +#defineMT9P031_H_BLANKING_VALUE0 +#define MT9P031_V_BLANKING 0x06 +#defineMT9P031_V_BLANKING_VALUE25 +#define MT9P031_OUTPUT_CONTROL 0x07 +#defineMT9P031_OUTPUT_CONTROL_CEN 2 +#defineMT9P031_OUTPUT_CONTROL_SYN 1 +#define MT9P031_SHUTTER_WIDTH_UPPER0x08 +#define MT9P031_SHUTTER_WIDTH 0x09 +#defineMT9P031_PLL_CONTROL 0x10 +#defineMT9P031_PLL_CONTROL_PWROFF 0x0050 +#defineMT9P031_PLL_CONTROL_PWRON 0x0051 +#defineMT9P031_PLL_CONTROL_USEPLL 0x0052 +#defineMT9P031_PLL_CONFIG_10x11 +#defineMT9P031_PLL_CONFIG_1_M_48MHZ0x5000 +#defineMT9P031_PLL_CONFIG_1_N_48MHZ0x05 +#defineMT9P031_PLL_CONFIG_1_M_96MHZ0x3600 +#defineMT9P031_PLL_CONFIG_1_N_96MHZ0x05 +#defineMT9P031_PLL_CONFIG_20x12 +#defineMT9P031_PLL_CONFIG_2_P1_48MHZ 5 +#defineMT9P031_PLL_CONFIG_2_P1_96MHZ 2 +#define
[PATCH 1/7] s5p-fimc: Fix possible memory leak during capture devnode registration
Add missing kfree on the error path. Reported-by: Tomasz Stanislawski t.stanisl...@samsung.com Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/video/s5p-fimc/fimc-capture.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c b/drivers/media/video/s5p-fimc/fimc-capture.c index d142b40..7e66455 100644 --- a/drivers/media/video/s5p-fimc/fimc-capture.c +++ b/drivers/media/video/s5p-fimc/fimc-capture.c @@ -903,6 +903,7 @@ err_vd_reg: err_v4l2_reg: v4l2_device_unregister(v4l2_dev); err_info: + kfree(ctx); dev_err(fimc-pdev-dev, failed to install\n); return ret; } -- 1.7.5.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Does omap3isp driver inherit controls of attached sensors?
Hi, I'm trying to add VFLIP control to the mt9p031 driver (don't worry Guennadi, I won't send the patch yet). For that purpose I've followed the code in mt9v032 sensor. When I try to query available controls using yavta I get the following: root@beagleboard:~# ./media-ctl -e OMAP3 ISP CCDC output /dev/video2 root@beagleboard:~# ./yavta -l /dev/video2 Device /dev/video2 opened: OMAP3 ISP CCDC output (media). No control found. As I have read here [1], drivers using subdevices should inherit their controls. Is this the case with omap3isp? [1] http://lxr.linux.no/#linux+v2.6.39/Documentation/video4linux/v4l2-controls.txt -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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: [linux-dvb] XC4000 patches for kernel 2.6.37.2
Em 02-06-2011 07:52, Devin Heitmueller escreveu: 2011/5/31 Dmitri Belimov d.beli...@gmail.com: Is it possible make some patches and add support xc4000 into kernel? With my best regards, Dmitry. What needs to happen here is somebody needs to prepare a patch series which contains all the relevant patches, including the SOBs. This is entirely an janitorial task which can be done by anyone and frankly I don't have time for this sort of crap anymore. Any volunteers? All my patches have my SOB attached. I explicitly got Davide's permission to add his SOB to his original patch, but it's not in the HG tree since I got the permission after I committed his change to my repo. I can forward the email with his SOB so the person constructing the tree can add it on (as well as my SOB to preserve the chain of custody). Secondly, we need to build a firmware image which is based off of the *actual* xceive firmware sources, so that we can be confident that all the blobs are from the same firmware revision and so that we can maintain them going forward. I can provide them off-list to someone willing to do this work and testing. Istann_v's firmware image is based off of i2c dumps and extracted by hand from disassembled firmware, which is less than ideal from an ongoing maintenance perspective. And of course it's worth mentioning that the driver itself still needs a ton of cleanup, doesn't meet the coding standards, and wouldn't be accepted upstream in its current state. Somebody will need to do the work to clean up the driver, as well as testing to make sure he/she didn't cause any regressions. In summary, here are the four things that need to happen: 1. Assemble tree with current patches It is probably easier for me to do this step, as I have my hg import scripts. However, as I don't have the PCTV devices added at dib0700, I can't test. OK, I did this work, as it just took me a few minutes to rebase patches 1 and 2. I didn't apply the patches that started with djh since they seemed to be a few hacks during the development time. The tree is at: git://linuxtv.org/mchehab/experimental.git branch xc4000 There are two warnings there that needs to be fixed: drivers/media/common/tuners/xc4000.c:1293: warning: ‘xc4000_is_firmware_loaded’ defined but not used drivers/media/common/tuners/xc4000.c: In function ‘check_firmware.clone.0’: drivers/media/common/tuners/xc4000.c:1107: warning: ‘version’ may be used uninitialized in this function Both seems to be trivial. A disclaimer notice here: I didn't make any cleanup at the code, (except by running a whitespace cleanup script) nor I've reviewed it. IMO, the next step is to test the rebases against a real hardware, and adding a few patches fixing it, if the rebases broke. The next step would be fix the CodingStyle, and run checkpatch.pl. There aren't many CodingStyle warnings/errors (13 errors, 28 warnings). Most of the errors are due to the excess usage of printk's for debug, and due to some obsolete code commented with //. 2. Construct valid firmware image off of current sources 3. Cleanup/coding style 4. Testing Now that we've got a bunch of people who are interested in seeing this upstream, who is going to volunteer to do which items in the above list? Devin -- 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 v2] v4l: add control definitions for codec devices.
From: Jeongtae Park [mailto:jtp.p...@samsung.com] Sent: 02 June 2011 09:44 To: 'Kamil Debski'; linux-media@vger.kernel.org Cc: jaeryul...@samsung.com; june@samsung.com; janghyuck@samsung.com; kyungmin.p...@samsung.com; younglak1004@samsung.com; 'Marek Szyprowski' Subject: RE: [RFC/PATCH v2] v4l: add control definitions for codec devices. Hi, Thank you for your nice work. Here are my some comments. Hi, Thanks for your comments. I think I must have posted the wrong patch file... I will send the proper one, with some of your suggestion in a minute. -Original Message- From: Kamil Debski [mailto:k.deb...@samsung.com] Sent: Tuesday, May 31, 2011 6:08 PM Cc: m.szyprow...@samsung.com; kyungmin.p...@samsung.com; k.deb...@samsung.com; jaeryul...@samsung.com; hverk...@xs4all.nl; laurent.pinch...@ideasonboard.com; jtp.p...@samsung.com Subject: [RFC/PATCH v2] v4l: add control definitions for codec devices. Hi, This is a second version of the patch that adds controls for the codec family of devices. I have implemented the suggestions I got from Hans Verkuil on the #v4l channel. Change log: - rename V4L2_CID_MIN_REQ_BUFS_(CAP/OUT) to V4L2_CID_MIN_BUFFERS_FOR_(CAPTURE/OUTPUT) - use existing controls for GOP size, number of frames and GOP closure - remove frame rate controls (in favour of the S_PARM call) - split level into separate controls for MPEG4 and H264 I would welcome further comments. Best regards, Kamil Debski Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Documentation/DocBook/v4l/controls.xml | 733 include/linux/videodev2.h | 147 +++ 2 files changed, 880 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index 6880798..7c2df42 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -325,6 +325,22 @@ minimum value disables backlight compensation./entry constantV4L2_CID_ILLUMINATORS_2/constant + 1)./entry /row row + [snip] + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_MAX_REF_PIC/constantnbsp;/en try + entryboolean/entry + /row + rowentry spanname=descrThe maximum number of reference pictures used for encoding./entry + /row Is it boolean type? It is not, a copy-paste mistake on my side. [snip] + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_BETA/constant nbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrLoop filter alpha coefficient, defined in the standard./entry + /row alpha - beta. I agree. [snip] + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE/constantnbsp; /entry + entryboolean/entry + /row + rowentry spanname=descrPadding enable - use a color instead of repeating border pixels./entry + /row The description may be wrong. Thanks for pointing this out. + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_MB_RC_ENABLE/constantnbs p;/entry + entryboolean/entry + /row + rowentry spanname=descrMacroblock level rate control enable for H264./entry + /row + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_FRAME_RATE_NOMINATOR/constant nbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrFrames per second - nominator./entry + /row Removed as you mentioned. Yes, I think I had to mix up the patches that got sent. + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_FRAME_RATE_DENOMINATOR/constant nbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrFrames per second - denominator/entry + /row + Removed as you mentioned. Ditto. [snip] + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_VBV_BUF_SIZE/constantnbsp;/e ntry + entryinteger/entry + /row + rowentry spanname=descrQuantization parameter for an P frame./entry + /row The description may be wrong, How about this? 'The VBV buffer size in kilo bytes, it used as a limitation of frame skip' I agree. + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_OPEN_GOP/constantnbsp;/ entry +
[RFC/PATCH v3] v4l: add control definitions for codec devices.
Hi, This is a third version of the patch that adds controls for the codec family of devices. I have implemented the suggestions to v1 I got from Hans Verkuil on the #v4l channel. Also I have addressed comments to v2 by Jeongtae Park. Changes from v2 to v3: - added MVC anc SVC profiles to H264 - some fixes in in the documentation - remove V4L2_CID_MPEG_VIDEO_INTERLACE in favour of interlace v4l2_field in v4l2_pix_format Changes from v1 to v2: - rename V4L2_CID_MIN_REQ_BUFS_(CAP/OUT) to V4L2_CID_MIN_BUFFERS_FOR_(CAPTURE/OUTPUT) - use existing controls for GOP size, number of frames and GOP closure - remove frame rate controls (in favour of the S_PARM call) - split level into separate controls for MPEG4 and H264 I would welcome further comments. Best regards, Kamil Debski Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Documentation/DocBook/v4l/controls.xml | 774 include/linux/videodev2.h | 149 ++ 2 files changed, 923 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index 6880798..3c3c709 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -325,6 +325,22 @@ minimum value disables backlight compensation./entry constantV4L2_CID_ILLUMINATORS_2/constant + 1)./entry /row row + entryconstantV4L2_CID_MIN_BUFFERS_FOR_CAPTURE/constant/entry + entryinteger/entry + entryThis is a read only control that can be read by the application +and used as a hint to determine the number of CAPTURE buffer to pass to REQBUFS. +The value is the minimum number of CAPTURE buffer that it necessary for hardware +to work./entry + /row + row + entryconstantV4L2_CID_MIN_BUFFERSS_FOR_OUTPUT/constant/entry + entryinteger/entry + entryThis is a read only control that can br read by the application +and used as a hint to determine the number of OUTPUT buffer to pass to REQBUFS. +The value is the minimum number of OUTPUT buffer that it necessary for hardware +to work./entry + /row + row entryconstantV4L2_CID_PRIVATE_BASE/constant/entry entry/entry entryID of the first custom (driver specific) control. @@ -1409,6 +1425,764 @@ of the video. The supplied 32-bit integer is interpreted as follows (bit /tbody /entrytbl /row + + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrIf enabled the decoder expects a single slice in one buffer, otherwise +the decoder expects a single frame in one input buffer./entry + /row + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_VUI_AR_ENABLE/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrEnable writing aspect ratio in the Video Usability Information./entry + /row + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_VUI_AR_IDC/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrVUI aspect ratio IDC for H.264 encoding. The value is defined in VUI Table +E-1 in the standard. + /entry + /row + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_EXT_SAR_WIDTH/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrExtended sample aspect ratio width for H.264 VUI encoding./entry + /row + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_EXT_SAR_HEIGHT/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrExtended sample aspect ratio height for H.264 VUI encoding./entry + /row + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_LEVEL/constantnbsp;/entry + entryenumnbsp;v4l2_mpeg_level/entry + /row + rowentry spanname=descrThe level information for stream. +Possible values are:/entry + /row + row + entrytbl spanname=descr cols=2 + tbody valign=top + row + entryconstantV4L2_MPEG_VIDEO_LEVEL_0/constantnbsp;/entry + entryLevel 0/entry + /row + row +
[PATCH 1/1] V4L/DVB: mt9v011: Fixed incorrect value for the first valid column
According to the datasheet (page 8), the first optical clear pixel-column is not at position 14. The correct/recommended value is 20. Without this patch there is a dark line on the left side of the image. Signed-off-by: Johannes Obermaier johannes.oberma...@gmail.com --- drivers/media/video/mt9v011.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/mt9v011.c b/drivers/media/video/mt9v011.c index 4904d25..a6cf05a 100644 --- a/drivers/media/video/mt9v011.c +++ b/drivers/media/video/mt9v011.c @@ -286,7 +286,7 @@ static void set_res(struct v4l2_subdev *sd) * be missing. */ - hstart = 14 + (640 - core-width) / 2; + hstart = 20 + (640 - core-width) / 2; mt9v011_write(sd, R02_MT9V011_COLSTART, hstart); mt9v011_write(sd, R04_MT9V011_WIDTH, core-width); mt9v011_write(sd, R05_MT9V011_HBLANK, 771 - core-width); -- 1.6.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] V4L/DVB: mt9v011: Fixed incorrect value for the first valid column
According to the datasheet (page 8), the first optical clear pixel-column is not at position 14. The correct/recommended value is 20. Without this patch there is a dark line on the left side of the image. Signed-off-by: Johannes Obermaier johannes.oberma...@gmail.com --- drivers/media/video/mt9v011.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/mt9v011.c b/drivers/media/video/mt9v011.c index 4904d25..a6cf05a 100644 --- a/drivers/media/video/mt9v011.c +++ b/drivers/media/video/mt9v011.c @@ -286,7 +286,7 @@ static void set_res(struct v4l2_subdev *sd) * be missing. */ - hstart = 14 + (640 - core-width) / 2; + hstart = 20 + (640 - core-width) / 2; mt9v011_write(sd, R02_MT9V011_COLSTART, hstart); mt9v011_write(sd, R04_MT9V011_WIDTH, core-width); mt9v011_write(sd, R05_MT9V011_HBLANK, 771 - core-width); -- 1.6.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] V4L/DVB: mt9v011: Added exposure for mt9v011
There are problems when you use this camera/sensor in a very bright room or
outside. The image is completely white, because it is overexposed. The driver
uses a default value which is not suitable for all environments.
This patch makes it possible to adjust the exposure time by youself. I found
out by logging the i2c-data, that the windows driver for this sensor is doing
this, too.
I tested the camera on a sunny day and after adjusting the exposure time, I was
able to see a very good image.
Signed-off-by: Johannes Obermaier johannes.oberma...@gmail.com
---
drivers/media/video/mt9v011.c | 22 +-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/mt9v011.c b/drivers/media/video/mt9v011.c
index a6cf05a..fbbd018 100644
--- a/drivers/media/video/mt9v011.c
+++ b/drivers/media/video/mt9v011.c
@@ -59,6 +59,15 @@ static struct v4l2_queryctrl mt9v011_qctrl[] = {
.default_value = 0x0020,
.flags = 0,
}, {
+ .id = V4L2_CID_EXPOSURE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Exposure,
+ .minimum = 0,
+ .maximum = 2047,
+ .step = 1,
+ .default_value = 0x01fc,
+ .flags = 0,
+ }, {
.id = V4L2_CID_RED_BALANCE,
.type = V4L2_CTRL_TYPE_INTEGER,
.name = Red Balance,
@@ -105,7 +114,7 @@ struct mt9v011 {
unsigned hflip:1;
unsigned vflip:1;
- u16 global_gain, red_bal, blue_bal;
+ u16 global_gain, exposure, red_bal, blue_bal;
};
static inline struct mt9v011 *to_mt9v011(struct v4l2_subdev *sd)
@@ -184,6 +193,9 @@ static void set_balance(struct v4l2_subdev *sd)
{
struct mt9v011 *core = to_mt9v011(sd);
u16 green1_gain, green2_gain, blue_gain, red_gain;
+ u16 exposure;
+
+ exposure = core-exposure;
green1_gain = core-global_gain;
green2_gain = core-global_gain;
@@ -198,6 +210,7 @@ static void set_balance(struct v4l2_subdev *sd)
mt9v011_write(sd, R2E_MT9V011_GREEN_2_GAIN, green1_gain);
mt9v011_write(sd, R2C_MT9V011_BLUE_GAIN, blue_gain);
mt9v011_write(sd, R2D_MT9V011_RED_GAIN, red_gain);
+ mt9v011_write(sd, R09_MT9V011_SHUTTER_WIDTH, exposure);
}
static void calc_fps(struct v4l2_subdev *sd, u32 *numerator, u32 *denominator)
@@ -338,6 +351,9 @@ static int mt9v011_g_ctrl(struct v4l2_subdev *sd, struct
v4l2_control *ctrl)
case V4L2_CID_GAIN:
ctrl-value = core-global_gain;
return 0;
+ case V4L2_CID_EXPOSURE:
+ ctrl-value = core-exposure;
+ return 0;
case V4L2_CID_RED_BALANCE:
ctrl-value = core-red_bal;
return 0;
@@ -392,6 +408,9 @@ static int mt9v011_s_ctrl(struct v4l2_subdev *sd, struct
v4l2_control *ctrl)
case V4L2_CID_GAIN:
core-global_gain = ctrl-value;
break;
+ case V4L2_CID_EXPOSURE:
+ core-exposure = ctrl-value;
+ break;
case V4L2_CID_RED_BALANCE:
core-red_bal = ctrl-value;
break;
@@ -598,6 +617,7 @@ static int mt9v011_probe(struct i2c_client *c,
}
core-global_gain = 0x0024;
+ core-exposure = 0x01fc;
core-width = 640;
core-height = 480;
core-xtal = 2700; /* Hz */
--
1.6.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] XC4000 patches for kernel 2.6.37.2
Now I understood how thing works here, and it clear to me, why the xc4000 driver is not being included in mainline V4L2. It will be lots of commitments and hard work to be the maintainer, and I respect Mr. Devin's choice and decisions. There are several peoples that are interested in this driver, such as Mr. Istvan. I realized this driver does not have huge users/audiences, but still there are peoples who really need it. But, yeah, not everybody can 'port' the driver each time Linux kernel or V4L2 version being updated. In this case, IF no one is able to maintains the driver, how others can benefit the 'updated' driver or patches for the new V4L2 or Linux releases? At the moment I still be able to port and test it for my private use. Sometime I sent the patches to Mr. Istvan to be included in his xc4000 driver's website, for other users to use it. BTW, I am not a programmer. I am just a system administrator, who only like to use shell scripts, awk, sed and grep. I only know how 'read' C, and can do SIMPLE 'porting' and testing tasks :). Still I really hope other developers able to include the analog TV/FM tuning and S-Video input feature to PCTV-340e. Anyway, if this driver is not elligible to be included in V4L2 mainline, I know where to 'push' my patches. :) Thank you. On 2011-06-02, Devin Heitmueller dheitmuel...@kernellabs.com wrote: 2011/5/31 Dmitri Belimov d.beli...@gmail.com: Is it possible make some patches and add support xc4000 into kernel? With my best regards, Dmitry. What needs to happen here is somebody needs to prepare a patch series which contains all the relevant patches, including the SOBs. This is entirely an janitorial task which can be done by anyone and frankly I don't have time for this sort of crap anymore. Any volunteers? All my patches have my SOB attached. I explicitly got Davide's permission to add his SOB to his original patch, but it's not in the HG tree since I got the permission after I committed his change to my repo. I can forward the email with his SOB so the person constructing the tree can add it on (as well as my SOB to preserve the chain of custody). Secondly, we need to build a firmware image which is based off of the *actual* xceive firmware sources, so that we can be confident that all the blobs are from the same firmware revision and so that we can maintain them going forward. I can provide them off-list to someone willing to do this work and testing. Istann_v's firmware image is based off of i2c dumps and extracted by hand from disassembled firmware, which is less than ideal from an ongoing maintenance perspective. And of course it's worth mentioning that the driver itself still needs a ton of cleanup, doesn't meet the coding standards, and wouldn't be accepted upstream in its current state. Somebody will need to do the work to clean up the driver, as well as testing to make sure he/she didn't cause any regressions. In summary, here are the four things that need to happen: 1. Assemble tree with current patches 2. Construct valid firmware image off of current sources 3. Cleanup/coding style 4. Testing Now that we've got a bunch of people who are interested in seeing this upstream, who is going to volunteer to do which items in the above list? Devin -- 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 3/3] V4L/DVB: mt9v011: Fixed gain calculation
(This patch must be used AFTER the patch V4L/DVB: mt9v011: Added exposure for
mt9v011)
The implementation of the gain calculation for this sensor is incorrect. It is
only working for the first 127 values.
The reason is, that the gain cannot be set directly by writing a value into the
gain registers of the sensor. The gain register work this way (see datasheet
page 24): bits 0 to 6 are called initial gain. These are linear. But bits 7
and 8 (analog multiplicative factors) and bits 9 and 10 (digital
multiplicative factors) work completely different: Each of these bits increase
the gain by the factor 2. So if the bits 7-10 are 0011, 0110, 1100 or 0101 for
example, the gain from bits 0-6 is multiplied by 4. The order of the bits 7-10
is not important for the resulting gain. (But there are some recommended values
for low noise)
The current driver doesn't do this correctly: If the current gain is 000 0111
(127) and the gain is increased by 1, you would expect the image to become
brighter. But the image is completly dark, because the new gain is 000 1000
(128). This means: Initial gain of 0, multiplied by 2. The result is 0.
This patch adds a new function which does the gain calculation and also fixes
the same bug for red_balance and blue_balance. Additionally, the driver follows
the recommendation from the datasheet, which says, that the gain should always
be above 0x0020.
Signed-off-by: Johannes Obermaier johannes.oberma...@gmail.com
---
drivers/media/video/mt9v011.c | 63 +---
1 files changed, 52 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/mt9v011.c b/drivers/media/video/mt9v011.c
index fbbd018..893a8b8 100644
--- a/drivers/media/video/mt9v011.c
+++ b/drivers/media/video/mt9v011.c
@@ -54,7 +54,7 @@ static struct v4l2_queryctrl mt9v011_qctrl[] = {
.type = V4L2_CTRL_TYPE_INTEGER,
.name = Gain,
.minimum = 0,
- .maximum = (1 10) - 1,
+ .maximum = (1 12) - 1 - 0x0020,
.step = 1,
.default_value = 0x0020,
.flags = 0,
@@ -114,7 +114,8 @@ struct mt9v011 {
unsigned hflip:1;
unsigned vflip:1;
- u16 global_gain, exposure, red_bal, blue_bal;
+ u16 global_gain, exposure;
+ s16 red_bal, blue_bal;
};
static inline struct mt9v011 *to_mt9v011(struct v4l2_subdev *sd)
@@ -189,25 +190,65 @@ static const struct i2c_reg_value mt9v011_init_default[]
= {
{ R07_MT9V011_OUT_CTRL, 0x0002 }, /* chip enable */
};
+
+static u16 calc_mt9v011_gain(s16 lineargain)
+{
+
+ u16 digitalgain = 0;
+ u16 analogmult = 0;
+ u16 analoginit = 0;
+
+ if (lineargain 0)
+ lineargain = 0;
+
+ /* recommended minimum */
+ lineargain += 0x0020;
+
+ if (lineargain 2047)
+ lineargain = 2047;
+
+ if (lineargain 1023) {
+ digitalgain = 3;
+ analogmult = 3;
+ analoginit = lineargain / 16;
+ } else if (lineargain 511) {
+ digitalgain = 1;
+ analogmult = 3;
+ analoginit = lineargain / 8;
+ } else if (lineargain 255) {
+ analogmult = 3;
+ analoginit = lineargain / 4;
+ } else if (lineargain 127) {
+ analogmult = 1;
+ analoginit = lineargain / 2;
+ } else
+ analoginit = lineargain;
+
+ return analoginit + (analogmult 7) + (digitalgain 9);
+
+}
+
static void set_balance(struct v4l2_subdev *sd)
{
struct mt9v011 *core = to_mt9v011(sd);
- u16 green1_gain, green2_gain, blue_gain, red_gain;
+ u16 green_gain, blue_gain, red_gain;
u16 exposure;
+ s16 bal;
exposure = core-exposure;
- green1_gain = core-global_gain;
- green2_gain = core-global_gain;
+ green_gain = calc_mt9v011_gain(core-global_gain);
- blue_gain = core-global_gain +
- core-global_gain * core-blue_bal / (1 9);
+ bal = core-global_gain;
+ bal += (core-blue_bal * core-global_gain / (1 7));
+ blue_gain = calc_mt9v011_gain(bal);
- red_gain = core-global_gain +
- core-global_gain * core-blue_bal / (1 9);
+ bal = core-global_gain;
+ bal += (core-red_bal * core-global_gain / (1 7));
+ red_gain = calc_mt9v011_gain(bal);
- mt9v011_write(sd, R2B_MT9V011_GREEN_1_GAIN, green1_gain);
- mt9v011_write(sd, R2E_MT9V011_GREEN_2_GAIN, green1_gain);
+ mt9v011_write(sd, R2B_MT9V011_GREEN_1_GAIN, green_gain);
+ mt9v011_write(sd, R2E_MT9V011_GREEN_2_GAIN, green_gain);
mt9v011_write(sd, R2C_MT9V011_BLUE_GAIN, blue_gain);
mt9v011_write(sd, R2D_MT9V011_RED_GAIN, red_gain);
mt9v011_write(sd, R09_MT9V011_SHUTTER_WIDTH, exposure);
--
1.6.4.2
--
To unsubscribe from this list: send the line
Re: [linux-dvb] XC4000 patches for kernel 2.6.37.2
Em 02-06-2011 12:17, Devin Heitmueller escreveu:
On Thu, Jun 2, 2011 at 10:41 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
1. Assemble tree with current patches
It is probably easier for me to do this step, as I have my hg import
scripts. However, as I don't have the PCTV devices added at dib0700,
I can't test.
OK, I did this work, as it just took me a few minutes to rebase patches
1 and 2. I didn't apply the patches that started with djh since they
seemed to be a few hacks during the development time.
The tree is at:
git://linuxtv.org/mchehab/experimental.git branch xc4000
There are two warnings there that needs to be fixed:
drivers/media/common/tuners/xc4000.c:1293: warning:
‘xc4000_is_firmware_loaded’ defined but not used
drivers/media/common/tuners/xc4000.c: In function ‘check_firmware.clone.0’:
drivers/media/common/tuners/xc4000.c:1107: warning: ‘version’ may be used
uninitialized in this function
Both seems to be trivial.
A disclaimer notice here: I didn't make any cleanup at the code,
(except by running a whitespace cleanup script) nor I've reviewed it.
IMO, the next step is to test the rebases against a real hardware,
and adding a few patches fixing it, if the rebases broke.
The next step would be fix the CodingStyle, and run checkpatch.pl.
There aren't many CodingStyle warnings/errors (13 errors, 28 warnings).
Most of the errors are due to the excess usage of printk's for debug,
and due to some obsolete code commented with //.
Hi Mauro,
Thanks for taking this on. The tree you posted looks like a pretty
reasonable start. I agree that the djh - commits probably aren't
required as they are most just from rebasing the tree. We'll find out
from testing though whether this is true. There's one patch with
subject djh - more debugging might actually be needed, but we'll see
when users try the tree.
I was in doubt and I almost backported that one too, but it seemed better
to not add it to just remove it at the end.
Btw, it seems that a latter patch on your tree removed it. The only difference
between the git tree and your tree at xc4000.c/xc4000.h is:
$ diff -uprBw drivers/media/common/tuners/xc4000.c
/home/v4l/tmp/linux/drivers/media/common/tuners/xc4000.c
--- drivers/media/common/tuners/xc4000.c2011-06-02 11:36:19.0
-0300
+++ /home/v4l/tmp/linux/drivers/media/common/tuners/xc4000.c2011-06-02
10:48:34.0 -0300
@@ -1272,7 +1272,8 @@ static int xc4000_set_params(struct dvb_
XC4000_Standard[priv-video_standard].AudioMode);
if (ret != XC_RESULT_SUCCESS) {
printk(KERN_ERR xc4000: xc_SetTVStandard failed\n);
- return -EREMOTEIO;
+ /* DJH - do not return when it fails... */
+ //return -EREMOTEIO;
}
#ifdef DJH_DEBUG
ret = xc_set_IF_frequency(priv, priv-if_khz);
So, maybe the above patch also needs to be added there.
This provides a pretty good base for istan_v to work off of, since he
did a rather large amount of refactoring to get analog to work - which
I was unable to even try given the two devices I had can't do analog
support due to limitations in the dvb-usb framework.
Mohammad, it would be great if you could try out Mauro's tree, since
it should work as-is for the 340e.
If it doesn't, please try to apply the above patch.
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
Re: [linux-dvb] XC4000 patches for kernel 2.6.37.2
Em 02-06-2011 12:53, Mohammad Bahathir Hashim escreveu: Now I understood how thing works here, and it clear to me, why the xc4000 driver is not being included in mainline V4L2. It will be lots of commitments and hard work to be the maintainer, and I respect Mr. Devin's choice and decisions. There are several peoples that are interested in this driver, such as Mr. Istvan. I realized this driver does not have huge users/audiences, but still there are peoples who really need it. But, yeah, not everybody can 'port' the driver each time Linux kernel or V4L2 version being updated. In this case, IF no one is able to maintains the driver, how others can benefit the 'updated' driver or patches for the new V4L2 or Linux releases? Out of tree drivers tend to become obsolete on a few kernel releases, as the internal kernel API's were not designed to be stable, as we want innovation inside the kernel. So, people are free to change the internal APIs when needed. That's why the best way is to submit patches upstream as they're ready for it. At the moment I still be able to port and test it for my private use. Sometime I sent the patches to Mr. Istvan to be included in his xc4000 driver's website, for other users to use it. BTW, I am not a programmer. I am just a system administrator, who only like to use shell scripts, awk, sed and grep. I only know how 'read' C, and can do SIMPLE 'porting' and testing tasks :). Still I really hope other developers able to include the analog TV/FM tuning and S-Video input feature to PCTV-340e. Anyway, if this driver is not elligible to be included in V4L2 mainline, I know where to 'push' my patches. :) Almost all drivers are eligible to be included, but the author needs to submit them, or someone on their behalf. If the driver doesn't have enough quality or needs some fixes, the submitter may need to fix it or, eventually, move it to staging. With respect to xc4000, we need someone to test if the driver works after the backports. Please test it and answer to us with a Tested-by tag. After the tests, it would be great to apply any pending patches for xc4000 before cleaning it, as if we do the reverse, existing patches won't apply. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] davinci: dm646x: move vpif related code to driver core header from platform
Hi Mauro,
On Fri, May 20, 2011 at 19:28:49, Hadli, Manjunath wrote:
move vpif related code for capture and display drivers
from dm646x platform header file to vpif.h as these definitions
are related to driver code more than the platform or board.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Will you be taking this patch through your tree?
If not, with your ack, I can queue it for inclusion
through the ARM tree.
Thanks,
Sekhar
---
arch/arm/mach-davinci/include/mach/dm646x.h | 53 +---
drivers/media/video/davinci/vpif.h |1 +
drivers/media/video/davinci/vpif_capture.h |2 +-
drivers/media/video/davinci/vpif_display.h |1 +
include/media/davinci/vpif.h| 73
+++
5 files changed, 77 insertions(+), 53 deletions(-)
create mode 100644 include/media/davinci/vpif.h
diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h
b/arch/arm/mach-davinci/include/mach/dm646x.h
index 7a27f3f..245a1c0 100644
--- a/arch/arm/mach-davinci/include/mach/dm646x.h
+++ b/arch/arm/mach-davinci/include/mach/dm646x.h
@@ -17,6 +17,7 @@
#include linux/videodev2.h
#include linux/clk.h
#include linux/davinci_emac.h
+#include media/davinci/vpif.h
#define DM646X_EMAC_BASE (0x01C8)
#define DM646X_EMAC_MDIO_BASE(DM646X_EMAC_BASE + 0x4000)
@@ -36,58 +37,6 @@ int __init dm646x_init_edma(struct edma_rsv_info *rsv);
void dm646x_video_init(void);
-enum vpif_if_type {
- VPIF_IF_BT656,
- VPIF_IF_BT1120,
- VPIF_IF_RAW_BAYER
-};
-
-struct vpif_interface {
- enum vpif_if_type if_type;
- unsigned hd_pol:1;
- unsigned vd_pol:1;
- unsigned fid_pol:1;
-};
-
-struct vpif_subdev_info {
- const char *name;
- struct i2c_board_info board_info;
- u32 input;
- u32 output;
- unsigned can_route:1;
- struct vpif_interface vpif_if;
-};
-
-struct vpif_display_config {
- int (*set_clock)(int, int);
- struct vpif_subdev_info *subdevinfo;
- int subdev_count;
- const char **output;
- int output_count;
- const char *card_name;
-};
-
-struct vpif_input {
- struct v4l2_input input;
- const char *subdev_name;
-};
-
-#define VPIF_CAPTURE_MAX_CHANNELS2
-
-struct vpif_capture_chan_config {
- const struct vpif_input *inputs;
- int input_count;
-};
-
-struct vpif_capture_config {
- int (*setup_input_channel_mode)(int);
- int (*setup_input_path)(int, const char *);
- struct vpif_capture_chan_config chan_config[VPIF_CAPTURE_MAX_CHANNELS];
- struct vpif_subdev_info *subdev_info;
- int subdev_count;
- const char *card_name;
-};
-
void dm646x_setup_vpif(struct vpif_display_config *,
struct vpif_capture_config *);
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h
index 10550bd..e76dded 100644
--- a/drivers/media/video/davinci/vpif.h
+++ b/drivers/media/video/davinci/vpif.h
@@ -20,6 +20,7 @@
#include linux/videodev2.h
#include mach/hardware.h
#include mach/dm646x.h
+#include media/davinci/vpif.h
/* Maximum channel allowed */
#define VPIF_NUM_CHANNELS(4)
diff --git a/drivers/media/video/davinci/vpif_capture.h
b/drivers/media/video/davinci/vpif_capture.h
index 7a4196d..fa50b6b 100644
--- a/drivers/media/video/davinci/vpif_capture.h
+++ b/drivers/media/video/davinci/vpif_capture.h
@@ -28,7 +28,7 @@
#include media/v4l2-device.h
#include media/videobuf-core.h
#include media/videobuf-dma-contig.h
-#include mach/dm646x.h
+#include media/davinci/vpif.h
#include vpif.h
diff --git a/drivers/media/video/davinci/vpif_display.h
b/drivers/media/video/davinci/vpif_display.h
index b53aaa8..b531a01 100644
--- a/drivers/media/video/davinci/vpif_display.h
+++ b/drivers/media/video/davinci/vpif_display.h
@@ -23,6 +23,7 @@
#include media/v4l2-device.h
#include media/videobuf-core.h
#include media/videobuf-dma-contig.h
+#include media/davinci/vpif.h
#include vpif.h
diff --git a/include/media/davinci/vpif.h b/include/media/davinci/vpif.h
new file mode 100644
index 000..e4a4dc1
--- /dev/null
+++ b/include/media/davinci/vpif.h
@@ -0,0 +1,73 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * 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., 59 Temple Place, Suite
[cron job] v4l-dvb daily build: ERRORS
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:Thu Jun 2 19:00:42 CEST 2011 git hash:f9b51477fe540fb4c65a05027fdd6f2ecce4db3b gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media patches with review pending (14 patches)
Mauro Carvalho Chehab mche...@redhat.com wrote: This is the list of the patches currently on my queue (13 patches from patchwork and one patch that patchwork lost due to a database corruption). There's not much patches there, as I've applied most of the pending stuff. Unfortunately, however, patchwork is not reliable. I noticed at least 2 patches lost when reviewing the patch series. I've applied one of them manually. So, please point me if is there a pending patch that I didn't catch. Thanks! Mauro == Patches for Manu Abraham abraham.m...@gmail.com review == Jun,11 2010: stb0899: Removed an extra byte sent at init on DiSEqC bus http://patchwork.kernel.org/patch/105621 Florent AUDEBERT florent.audeb...@anevia.com Aug, 7 2010: Refactor Mantis DMA transfer to deliver 16Kb TS data per interrupt http://patchwork.kernel.org/patch/118173 Marko Ristola marko.rist...@kolumbus.fi May, 4 2011: stb0899: Fix not locking DVB-S transponder http://patchwork.kernel.org/patch/753382 Lutz Sammer john...@gmx.net May,21 2011: Disable dynamic current limit for ttpci budget cards http://patchwork.kernel.org/patch/805872 Guy Martin gms...@tuxicoman.be May,23 2011: Increase a timeout, so that bad scheduling does not accidentially caus http://patchwork.kernel.org/patch/809002 Hans Petter Selasky hsela...@c2i.net May,25 2011: Add remote control support for mantis Christoph Pinkl christoph.pi...@gmail.com May,24 2011: Fix the derot zig-zag to work with TT-USB2.0 TechnoTrend. http://patchwork.kernel.org/patch/826102 Hans Petter Selasky hsela...@c2i.net Jun, 1 2011: stv090x: set status bits when there is no lock http://patchwork.kernel.org/patch/840602 Guy Martin gms...@tuxicoman.be The RC support for mantis is a patch that it used to be on patchwork, but got lost. == Waiting for Hernán Ordialesh.ordia...@gmail.com comments and new patch == May, 3 2011: Adding support to the Geniatech/MyGica SBTVD Stick S870 remote control http://patchwork.kernel.org/patch/751702 Mauro Carvalho Chehab mche...@redhat.com == Waiting for Tomasz G. Burak tome...@op.pl comments and new patch == Feb, 7 2011: DVB-USB: Remote Control for TwinhanDTV StarBox DVB-S USB and cloneshttp://patchwork.kernel.org/patch/751832 Tomasz G. Burak tome...@op.pl == Patches for Andy Walls awa...@md.metrocast.net review == May,25 2011: ivtv: use display information in info not in var for panning http://patchwork.kernel.org/patch/815492 Laurent Pinchart laurent.pinch...@ideasonboard.com == Patches waiting my tests with mb86a20s/ISDB-T == May,19 2011: saa7134-dvb.c kworld_sbtvd http://patchwork.kernel.org/patch/798782 Manoel Pinheiro pinus...@hotmail.com May,19 2011: [RFC] add i2c_gate_ctrl to mb86a20s.c http://patchwork.kernel.org/patch/799532 Manoel Pinheiro pinus...@hotmail.com == Waiting for Oliver Endrisso.endr...@gmx.de review == May,12 2011: ngene: blocking and nonblocking io for sec0 http://patchwork.kernel.org/patch/780072 Issa Gorissen flo...@usa.net Number of pending patches per reviewer: Manu Abraham abraham.m...@gmail.com : 8 Mauro Carvalho Chehab mche...@redhat.com: 2 Andy Walls awa...@md.metrocast.net : 1 Hernán Ordiales h.ordia...@gmail.com: 1 Oliver Endriss o.endr...@gmx.de : 1 Tomasz G. Burak tome...@op.pl This pull request from a few days ago contained Laurent's ivtvfb patch: http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/33251 Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/6] iommu: generic api migration and grouping
First stab at iommu consolidation:
- Migrate OMAP's iommu driver to the generic iommu API. With this in hand,
users can now start using the generic iommu layer instead of calling
omap-specific iommu API.
New code that requires functionality missing from the generic iommu api,
will add that functionality in the generic framework (e.g. adding framework
awareness to multi page sizes, supported by the underlying hardware, will
avoid the otherwise-inevitable code duplication when mapping a memory
region).
OMAP-specific api that is still exposed in the omap iommu driver can
now be either moved to the generic iommu framework, or just removed (if not
used).
This api (and other omap-specific primitives like struct iommu) needs to
be omapified (i.e. renamed to include an 'omap_' prefix). At this early
point of this patch set this is too much churn though, so I'll do that
in the following iteration, after (and if), the general direction is
accepted.
- Migrate OMAP's iovmm (virtual memory manager) driver to the generic
iommu API. With this in hand, iovmm no longer uses omap-specific api
for mapping/unmapping operations. Nevertheless, iovmm is still coupled
with omap's iommu even with this change: it assumes omap page sizes,
and it uses omap's iommu objects to maintain its internal state.
Further generalizing of iovmm strongly depends on our broader plans for
providing a generic virtual memory manager and allocation framework
(which, as discussed, should be separated from a specific mapper).
iovmm has a mainline user: omap3isp, and therefore must be maintained,
but new potential users will either have to generalize it, or come up
with a different generic framework that will replace it.
- Migrate OMAP's iommu mainline user, omap3isp, to the generic API as well
(so it doesn't break). As with iovmm, omap3isp still depends on
omap's iommu, mainly because iovmm depends on it, but also for
iommu context saving and restoring.
It is definitely desirable to completely remove omap3isp's dependency
on the omap-specific iommu layer, and that will be possible as the
required functionality will be added to generic framework.
- Create a dedicated iommu drivers folder (and put the base iommu code there)
- Move OMAP's and MSM's iommu drivers to that drivers iommu folder
Putting all iommu drivers together will ease finding similarities
between different platforms, with the intention of solving problems once,
in a generic framework which everyone can use.
I've only moved the omap and msm implementations for now, to demonstrate
the idea (and support the ARM diet :), but if this is found desirable,
we can bring in intel-iommu.c and amd_iommu.c as well.
Meta:
- This patch set is not bisectable; it was splitted (and ordered) this way
to ease its review. Later iterations of this patch set will fix that
(most likely by squashing the first three patches)
- Based on and tested with 3.0-rc1
- OMAP's iommu code was tested on both OMAP3 and OMAP4
- omap3isp code was tested with a sensor-less OMAP3 (memory-to-memory only)
(thanks Laurent Pinchart for showing me the magic needed to test omap3isp :)
- MSM code was only compile tested
Ohad Ben-Cohen (6):
omap: iommu: generic iommu api migration
omap: iovmm: generic iommu api migration
media: omap3isp: generic iommu api migration
drivers: iommu: move to a dedicated folder
omap: iommu/iovmm: move to dedicated iommu folder
msm: iommu: move to dedicated iommu drivers folder
arch/arm/mach-msm/Kconfig | 15 -
arch/arm/mach-msm/Makefile |2 +-
arch/arm/plat-omap/Kconfig | 12 -
arch/arm/plat-omap/Makefile|2 -
arch/arm/plat-omap/include/plat/iommu.h|3 +-
arch/arm/plat-omap/{ = include/plat}/iopgtable.h | 18 ++
arch/arm/plat-omap/include/plat/iovmm.h| 27 +-
arch/x86/Kconfig |5 +-
drivers/Kconfig|2 +
drivers/Makefile |1 +
drivers/base/Makefile |1 -
drivers/iommu/Kconfig | 32 +++
drivers/iommu/Makefile |5 +
drivers/{base = iommu}/iommu.c|0
.../mach-msm/iommu.c = drivers/iommu/msm-iommu.c |0
.../iommu/omap-iommu-debug.c |2 +-
.../iommu.c = drivers/iommu/omap-iommu.c | 290 +---
.../iovmm.c = drivers/iommu/omap-iovmm.c | 113 +---
drivers/media/video/Kconfig|2 +-
drivers/media/video/omap3isp/isp.c | 41 +++-
drivers/media/video/omap3isp/isp.h |3 +
drivers/media/video/omap3isp/ispccdc.c | 16 +-
drivers/media/video/omap3isp/ispstat.c |6 +-
[RFC 1/6] omap: iommu: generic iommu api migration
Migrate OMAP's iommu to the generic iommu api, so users can stay
generic, and non-omap-specific code can be removed and eventually
consolidated into a generic framework.
Tested on both OMAP3 and OMAP4.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap/Kconfig |7 +-
arch/arm/plat-omap/include/plat/iommu.h |3 +-
arch/arm/plat-omap/iommu.c | 288 +++
arch/arm/plat-omap/iopgtable.h | 18 ++
4 files changed, 278 insertions(+), 38 deletions(-)
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 49a4c75..1c3acb5 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -131,8 +131,13 @@ config OMAP_MBOX_KFIFO_SIZE
This can also be changed at runtime (via the mbox_kfifo_size
module parameter).
+config IOMMU_API
+ bool
+
+#can't be tristate; iommu api doesn't support un-registration
config OMAP_IOMMU
- tristate
+ bool
+ select IOMMU_API
config OMAP_IOMMU_DEBUG
tristate Export OMAP IOMMU internals in DebugFS
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 174f1b9..db1c492 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -167,8 +167,6 @@ extern void iopgtable_lookup_entry(struct iommu *obj, u32
da, u32 **ppgd,
extern size_t iopgtable_clear_entry(struct iommu *obj, u32 iova);
extern int iommu_set_da_range(struct iommu *obj, u32 start, u32 end);
-extern struct iommu *iommu_get(const char *name);
-extern void iommu_put(struct iommu *obj);
extern int iommu_set_isr(const char *name,
int (*isr)(struct iommu *obj, u32 da, u32 iommu_errs,
void *priv),
@@ -185,5 +183,6 @@ extern int foreach_iommu_device(void *data,
extern ssize_t iommu_dump_ctx(struct iommu *obj, char *buf, ssize_t len);
extern size_t dump_tlb_entries(struct iommu *obj, char *buf, ssize_t len);
+struct device *omap_find_iommu_device(const char *name);
#endif /* __MACH_IOMMU_H */
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 34fc31e..f06e99c 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -18,6 +18,8 @@
#include linux/ioport.h
#include linux/clk.h
#include linux/platform_device.h
+#include linux/iommu.h
+#include linux/mutex.h
#include asm/cacheflush.h
@@ -30,6 +32,19 @@
(__i (n)) (cr = __iotlb_read_cr((obj), __i), true); \
__i++)
+/**
+ * struct omap_iommu_domain - omap iommu domain
+ * @pgtable: the page table
+ * @iommu_dev: an omap iommu device attached to this domain. only a single
+ * iommu device can be attached for now.
+ * @lock: domain lock, should be taken when attaching/detaching
+ */
+struct omap_iommu_domain {
+ u32 *pgtable;
+ struct iommu *iommu_dev;
+ struct mutex lock;
+};
+
/* accommodate the difference between omap1 and omap2/3 */
static const struct iommu_functions *arch_iommu;
@@ -852,31 +867,50 @@ int iommu_set_da_range(struct iommu *obj, u32 start, u32
end)
EXPORT_SYMBOL_GPL(iommu_set_da_range);
/**
- * iommu_get - Get iommu handler
- * @name: target iommu name
+ * omap_find_iommu_device() - find an omap iommu device by name
+ * @name: name of the iommu device
+ *
+ * The generic iommu API requires the caller to provide the device
+ * he wishes to attach to a certain iommu domain. Users of that API
+ * may look up the device using PCI credentials when relevent, and when
+ * not, this helper should be used to find a specific iommu device by name.
+ *
+ * This may be relevant to other platforms as well (msm ?) so consider
+ * moving this to the generic iommu framework.
+ */
+struct device *omap_find_iommu_device(const char *name)
+{
+ return driver_find_device(omap_iommu_driver.driver, NULL,
+ (void *)name,
+ device_match_by_alias);
+}
+EXPORT_SYMBOL_GPL(omap_find_iommu_device);
+
+/**
+ * omap_iommu_attach() - attach iommu device to an iommu domain
+ * @dev: target omap iommu device
+ * @iopgd: page table
**/
-struct iommu *iommu_get(const char *name)
+static struct iommu *omap_iommu_attach(struct device *dev, u32 *iopgd)
{
int err = -ENOMEM;
- struct device *dev;
- struct iommu *obj;
-
- dev = driver_find_device(omap_iommu_driver.driver, NULL, (void *)name,
-device_match_by_alias);
- if (!dev)
- return ERR_PTR(-ENODEV);
-
- obj = to_iommu(dev);
+ struct iommu *obj = to_iommu(dev);
mutex_lock(obj-iommu_lock);
- if (obj-refcount++ == 0) {
- err = iommu_enable(obj);
- if (err)
- goto err_enable;
- flush_iotlb_all(obj);
+ /* an iommu device can only be attached once
[RFC 4/6] drivers: iommu: move to a dedicated folder
Create a dedicated folder for iommu drivers, and move the base
iommu implementation over there.
Grouping the varius iommu drivers in a single location will help
finding similar problems shared by different platforms, so they
could be solved once, in the iommu framework, instead of solved
differently (or duplicated) in each driver.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-msm/Kconfig |3 ---
arch/arm/plat-omap/Kconfig |3 ---
arch/x86/Kconfig|5 ++---
drivers/Kconfig |2 ++
drivers/Makefile|1 +
drivers/base/Makefile |1 -
drivers/iommu/Kconfig |3 +++
drivers/iommu/Makefile |1 +
drivers/{base = iommu}/iommu.c |0
9 files changed, 9 insertions(+), 10 deletions(-)
create mode 100644 drivers/iommu/Kconfig
create mode 100644 drivers/iommu/Makefile
rename drivers/{base = iommu}/iommu.c (100%)
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index 1516896..efb7b7d 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -205,9 +205,6 @@ config MSM_GPIOMUX
config MSM_V2_TLMM
bool
-config IOMMU_API
- bool
-
config MSM_SCM
bool
endif
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 1c3acb5..1bb1981 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -131,9 +131,6 @@ config OMAP_MBOX_KFIFO_SIZE
This can also be changed at runtime (via the mbox_kfifo_size
module parameter).
-config IOMMU_API
- bool
-
#can't be tristate; iommu api doesn't support un-registration
config OMAP_IOMMU
bool
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index da34972..460d573 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -685,6 +685,7 @@ config AMD_IOMMU
select SWIOTLB
select PCI_MSI
select PCI_IOV
+ select IOMMU_API
depends on X86_64 PCI ACPI
---help---
With this option you can enable support for AMD IOMMU hardware in
@@ -720,9 +721,6 @@ config SWIOTLB
config IOMMU_HELPER
def_bool (CALGARY_IOMMU || GART_IOMMU || SWIOTLB || AMD_IOMMU)
-config IOMMU_API
- def_bool (AMD_IOMMU || DMAR)
-
config MAXSMP
bool Enable Maximum number of SMP Processors and NUMA Nodes
depends on X86_64 SMP DEBUG_KERNEL EXPERIMENTAL
@@ -1945,6 +1943,7 @@ config PCI_CNB20LE_QUIRK
config DMAR
bool Support for DMA Remapping Devices (EXPERIMENTAL)
depends on PCI_MSI ACPI EXPERIMENTAL
+ select IOMMU_API
help
DMA remapping (DMAR) devices support enables independent address
translations for Direct Memory Access (DMA) from devices.
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 3bb154d..9d51318 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -126,4 +126,6 @@ source drivers/hwspinlock/Kconfig
source drivers/clocksource/Kconfig
+source drivers/iommu/Kconfig
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 09f3232..2f7a71a 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -122,3 +122,4 @@ obj-y += ieee802154/
obj-y += clk/
obj-$(CONFIG_HWSPINLOCK) += hwspinlock/
+obj-$(CONFIG_IOMMU_API)+= iommu/
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 4c5701c..5ab0d07 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -13,7 +13,6 @@ obj-$(CONFIG_FW_LOADER) += firmware_class.o
obj-$(CONFIG_NUMA) += node.o
obj-$(CONFIG_MEMORY_HOTPLUG_SPARSE) += memory.o
obj-$(CONFIG_SMP) += topology.o
-obj-$(CONFIG_IOMMU_API) += iommu.o
ifeq ($(CONFIG_SYSFS),y)
obj-$(CONFIG_MODULES) += module.o
endif
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
new file mode 100644
index 000..2c5dfb4
--- /dev/null
+++ b/drivers/iommu/Kconfig
@@ -0,0 +1,3 @@
+# IOMMU_API always gets selected by whoever wants it.
+config IOMMU_API
+ bool
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
new file mode 100644
index 000..241ba4c
--- /dev/null
+++ b/drivers/iommu/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_IOMMU_API) += iommu.o
diff --git a/drivers/base/iommu.c b/drivers/iommu/iommu.c
similarity index 100%
rename from drivers/base/iommu.c
rename to drivers/iommu/iommu.c
--
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
[RFC 6/6] msm: iommu: move to dedicated iommu drivers folder
This should ease finding similarities with other platforms, with the intention of solving problems once in a generic framework which everyone can use. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- arch/arm/mach-msm/Kconfig | 12 arch/arm/mach-msm/Makefile |2 +- drivers/iommu/Kconfig | 11 +++ drivers/iommu/Makefile |1 + .../mach-msm/iommu.c = drivers/iommu/msm-iommu.c |0 5 files changed, 13 insertions(+), 13 deletions(-) rename arch/arm/mach-msm/iommu.c = drivers/iommu/msm-iommu.c (100%) diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig index efb7b7d..14ebda1 100644 --- a/arch/arm/mach-msm/Kconfig +++ b/arch/arm/mach-msm/Kconfig @@ -148,18 +148,6 @@ config MACH_MSM8960_RUMI3 endmenu -config MSM_IOMMU - bool MSM IOMMU Support - depends on ARCH_MSM8X60 || ARCH_MSM8960 - select IOMMU_API - default n - help - Support for the IOMMUs found on certain Qualcomm SOCs. - These IOMMUs allow virtualization of the address space used by most - cores within the multimedia subsystem. - - If unsure, say N here. - config IOMMU_PGTABLES_L2 def_bool y depends on MSM_IOMMU MMU SMP CPU_DCACHE_DISABLE=n diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile index 9519fd2..0bf4648 100644 --- a/arch/arm/mach-msm/Makefile +++ b/arch/arm/mach-msm/Makefile @@ -3,7 +3,7 @@ obj-y += clock.o obj-$(CONFIG_DEBUG_FS) += clock-debug.o obj-$(CONFIG_MSM_VIC) += irq-vic.o -obj-$(CONFIG_MSM_IOMMU) += iommu.o iommu_dev.o devices-iommu.o +obj-$(CONFIG_MSM_IOMMU) += iommu_dev.o devices-iommu.o obj-$(CONFIG_ARCH_MSM7X00A) += dma.o irq.o acpuclock-arm11.o obj-$(CONFIG_ARCH_MSM7X30) += dma.o diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 57378ac..e083ff0 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -19,3 +19,14 @@ config OMAP_IOMMU_DEBUG the internal state of OMAP IOMMU in debugfs. Say N unless you know you need this. + +config MSM_IOMMU + bool MSM IOMMU Support + depends on ARCH_MSM8X60 || ARCH_MSM8960 + select IOMMU_API + help + Support for the IOMMUs found on certain Qualcomm SOCs. + These IOMMUs allow virtualization of the address space used by most + cores within the multimedia subsystem. + + If unsure, say N here. diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile index c094875..bfb000a 100644 --- a/drivers/iommu/Makefile +++ b/drivers/iommu/Makefile @@ -2,3 +2,4 @@ obj-$(CONFIG_IOMMU_API) += iommu.o obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o obj-$(CONFIG_OMAP_IOVMM) += omap-iovmm.o obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o +obj-$(CONFIG_MSM_IOMMU) += msm-iommu.o diff --git a/arch/arm/mach-msm/iommu.c b/drivers/iommu/msm-iommu.c similarity index 100% rename from arch/arm/mach-msm/iommu.c rename to drivers/iommu/msm-iommu.c -- 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
[RFC 5/6] omap: iommu/iovmm: move to dedicated iommu folder
Move OMAP's iommu drivers to the dedicated iommu drivers folder.
While OMAP's iovmm (virtual memory manager) driver does not strictly
belong to the iommu drivers folder, move it there as well, because
it's by no means OMAP-specific (in concept. technically it is still
coupled with the omap iommu), and exposing it will ease its generalization,
consolidation, or removal (once a generic virtual memory manager and allocator
would materialize).
Move omap's iommu debug driver to the generic folder as well, for the
same reasons.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap/Kconfig | 14 --
arch/arm/plat-omap/Makefile|2 --
arch/arm/plat-omap/{ = include/plat}/iopgtable.h |0
drivers/iommu/Kconfig | 18 ++
drivers/iommu/Makefile |3 +++
.../iommu/omap-iommu-debug.c |2 +-
.../iommu.c = drivers/iommu/omap-iommu.c |2 +-
.../iovmm.c = drivers/iommu/omap-iovmm.c |2 +-
drivers/media/video/Kconfig|2 +-
9 files changed, 25 insertions(+), 20 deletions(-)
rename arch/arm/plat-omap/{ = include/plat}/iopgtable.h (100%)
rename arch/arm/plat-omap/iommu-debug.c = drivers/iommu/omap-iommu-debug.c
(99%)
rename arch/arm/plat-omap/iommu.c = drivers/iommu/omap-iommu.c (99%)
rename arch/arm/plat-omap/iovmm.c = drivers/iommu/omap-iovmm.c (99%)
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 1bb1981..14f067f 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -131,20 +131,6 @@ config OMAP_MBOX_KFIFO_SIZE
This can also be changed at runtime (via the mbox_kfifo_size
module parameter).
-#can't be tristate; iommu api doesn't support un-registration
-config OMAP_IOMMU
- bool
- select IOMMU_API
-
-config OMAP_IOMMU_DEBUG
- tristate Export OMAP IOMMU internals in DebugFS
- depends on OMAP_IOMMU DEBUG_FS
- help
- Select this to see extensive information about
- the internal state of OMAP IOMMU in debugfs.
-
- Say N unless you know you need this.
-
config OMAP_IOMMU_IVA2
bool
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index f0233e6..9852622 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -18,8 +18,6 @@ obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
obj-$(CONFIG_ARCH_OMAP4) += omap_device.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
-obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o
-obj-$(CONFIG_OMAP_IOMMU_DEBUG) += iommu-debug.o
obj-$(CONFIG_CPU_FREQ) += cpu-omap.o
obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o
diff --git a/arch/arm/plat-omap/iopgtable.h
b/arch/arm/plat-omap/include/plat/iopgtable.h
similarity index 100%
rename from arch/arm/plat-omap/iopgtable.h
rename to arch/arm/plat-omap/include/plat/iopgtable.h
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 2c5dfb4..57378ac 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -1,3 +1,21 @@
# IOMMU_API always gets selected by whoever wants it.
config IOMMU_API
bool
+
+# can't be tristate; iommu api doesn't support un-registration
+config OMAP_IOMMU
+ bool
+ select IOMMU_API
+
+config OMAP_IOVMM
+ tristate
+ select OMAP_IOMMU
+
+config OMAP_IOMMU_DEBUG
+ tristate Export OMAP IOMMU internals in DebugFS
+ depends on OMAP_IOVMM DEBUG_FS
+ help
+ Select this to see extensive information about
+ the internal state of OMAP IOMMU in debugfs.
+
+ Say N unless you know you need this.
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 241ba4c..c094875 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -1 +1,4 @@
obj-$(CONFIG_IOMMU_API) += iommu.o
+obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
+obj-$(CONFIG_OMAP_IOVMM) += omap-iovmm.o
+obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
diff --git a/arch/arm/plat-omap/iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
similarity index 99%
rename from arch/arm/plat-omap/iommu-debug.c
rename to drivers/iommu/omap-iommu-debug.c
index f07cf2f..0f8c8dd 100644
--- a/arch/arm/plat-omap/iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -21,7 +21,7 @@
#include plat/iommu.h
#include plat/iovmm.h
-#include iopgtable.h
+#include plat/iopgtable.h
#define MAXCOLUMN 100 /* for short messages */
diff --git a/arch/arm/plat-omap/iommu.c b/drivers/iommu/omap-iommu.c
similarity index 99%
rename from arch/arm/plat-omap/iommu.c
rename to drivers/iommu/omap-iommu.c
index f06e99c..1526fea 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -25,7 +25,7 @@
#include plat/iommu.h
-#include iopgtable.h
+#include plat/iopgtable.h
#define for_each_iotlb_cr(obj, n, __i, cr) \
for (__i = 0;
[RFC 3/6] media: omap3isp: generic iommu api migration
First step towards migrating omap3isp to the generic iommu api.
At this point we still need a handle of the omap-specific iommu, mainly
because we highly depend on omap's iovmm.
Migration will be fully completed only once omap's iovmm will be generalized
(or replaced by a generic virtual memory manager framework).
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/media/video/omap3isp/isp.c | 41 +-
drivers/media/video/omap3isp/isp.h |3 ++
drivers/media/video/omap3isp/ispccdc.c | 16 ++--
drivers/media/video/omap3isp/ispstat.c |6 ++--
drivers/media/video/omap3isp/ispvideo.c |4 +-
5 files changed, 50 insertions(+), 20 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index 897a1cf..25bade9 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -80,6 +80,13 @@
#include isph3a.h
#include isphist.h
+/*
+ * this is provided as an interim solution until omap3isp doesn't need
+ * any omap-specific iommu API
+ */
+#define to_iommu(dev) \
+ (struct iommu *)platform_get_drvdata(to_platform_device(dev))
+
static unsigned int autoidle;
module_param(autoidle, int, 0444);
MODULE_PARM_DESC(autoidle, Enable OMAP3ISP AUTOIDLE support);
@@ -1975,7 +1982,8 @@ static int isp_remove(struct platform_device *pdev)
isp_cleanup_modules(isp);
omap3isp_get(isp);
- iommu_put(isp-iommu);
+ iommu_detach_device(isp-domain, isp-iommu_dev);
+ iommu_domain_free(isp-domain);
omap3isp_put(isp);
free_irq(isp-irq_num, isp);
@@ -2123,25 +2131,41 @@ static int isp_probe(struct platform_device *pdev)
}
/* IOMMU */
- isp-iommu = iommu_get(isp);
- if (IS_ERR_OR_NULL(isp-iommu)) {
- isp-iommu = NULL;
+ isp-iommu_dev = omap_find_iommu_device(isp);
+ if (!isp-iommu_dev) {
+ dev_err(isp-dev, omap_find_iommu_device failed\n);
ret = -ENODEV;
goto error_isp;
}
+ /* to be removed once iommu migration is complete */
+ isp-iommu = to_iommu(isp-iommu_dev);
+
+ isp-domain = iommu_domain_alloc();
+ if (!isp-domain) {
+ dev_err(isp-dev, can't alloc iommu domain\n);
+ ret = -ENOMEM;
+ goto error_isp;
+ }
+
+ ret = iommu_attach_device(isp-domain, isp-iommu_dev);
+ if (ret) {
+ dev_err(pdev-dev, can't attach iommu device: %d\n, ret);
+ goto free_domain;
+ }
+
/* Interrupt */
isp-irq_num = platform_get_irq(pdev, 0);
if (isp-irq_num = 0) {
dev_err(isp-dev, No IRQ resource\n);
ret = -ENODEV;
- goto error_isp;
+ goto detach_dev;
}
if (request_irq(isp-irq_num, isp_isr, IRQF_SHARED, OMAP3 ISP, isp)) {
dev_err(isp-dev, Unable to request IRQ\n);
ret = -EINVAL;
- goto error_isp;
+ goto detach_dev;
}
/* Entities */
@@ -2162,8 +2186,11 @@ error_modules:
isp_cleanup_modules(isp);
error_irq:
free_irq(isp-irq_num, isp);
+detach_dev:
+ iommu_detach_device(isp-domain, isp-iommu_dev);
+free_domain:
+ iommu_domain_free(isp-domain);
error_isp:
- iommu_put(isp-iommu);
omap3isp_put(isp);
error:
isp_put_clocks(isp);
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h
index 2620c40..1b54aa4 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -32,6 +32,7 @@
#include linux/io.h
#include linux/platform_device.h
#include linux/wait.h
+#include linux/iommu.h
#include plat/iommu.h
#include plat/iovmm.h
@@ -289,6 +290,8 @@ struct isp_device {
unsigned int subclk_resources;
struct iommu *iommu;
+ struct iommu_domain *domain;
+ struct device *iommu_dev;
struct isp_platform_callback platform_cb;
};
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c
index 39d501b..b59b06f 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -365,7 +365,7 @@ static void ccdc_lsc_free_request(struct isp_ccdc_device
*ccdc,
dma_unmap_sg(isp-dev, req-iovm-sgt-sgl,
req-iovm-sgt-nents, DMA_TO_DEVICE);
if (req-table)
- iommu_vfree(isp-iommu, req-table);
+ iommu_vfree(isp-domain, isp-iommu, req-table);
kfree(req);
}
@@ -437,8 +437,8 @@ static int ccdc_lsc_config(struct isp_ccdc_device *ccdc,
req-enable = 1;
- req-table = iommu_vmalloc(isp-iommu, 0, req-config.size,
- IOMMU_FLAG);
+ req-table =
[RFC 2/6] omap: iovmm: generic iommu api migration
Migrate omap's iovmm (virtual memory manager) to the generic iommu api.
This brings iovmm a step forward towards being completely non
omap-specific (it's still assuming omap's iommu page sizes, and also
maintaining state inside omap's internal iommu structure, but it no
longer calls omap-specific iommu map/unmap api).
Further generalizing of iovmm (or complete removal) should take place
together with broader plans of providing a generic virtual memory manager
and allocation framework (de-coupled from specific mappers).
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap/include/plat/iovmm.h | 27 +---
arch/arm/plat-omap/iovmm.c | 111 ++-
2 files changed, 82 insertions(+), 56 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/iovmm.h
b/arch/arm/plat-omap/include/plat/iovmm.h
index 32a2f6c..56ee2b9 100644
--- a/arch/arm/plat-omap/include/plat/iovmm.h
+++ b/arch/arm/plat-omap/include/plat/iovmm.h
@@ -13,6 +13,8 @@
#ifndef __IOMMU_MMAP_H
#define __IOMMU_MMAP_H
+#include linux/iommu.h
+
struct iovm_struct {
struct iommu*iommu; /* iommu object which this belongs to */
u32 da_start; /* area definition */
@@ -74,18 +76,21 @@ struct iovm_struct {
extern struct iovm_struct *find_iovm_area(struct iommu *obj, u32 da);
-extern u32 iommu_vmap(struct iommu *obj, u32 da,
+extern u32 iommu_vmap(struct iommu_domain *domain, struct iommu *obj, u32 da,
const struct sg_table *sgt, u32 flags);
-extern struct sg_table *iommu_vunmap(struct iommu *obj, u32 da);
-extern u32 iommu_vmalloc(struct iommu *obj, u32 da, size_t bytes,
- u32 flags);
-extern void iommu_vfree(struct iommu *obj, const u32 da);
-extern u32 iommu_kmap(struct iommu *obj, u32 da, u32 pa, size_t bytes,
- u32 flags);
-extern void iommu_kunmap(struct iommu *obj, u32 da);
-extern u32 iommu_kmalloc(struct iommu *obj, u32 da, size_t bytes,
- u32 flags);
-extern void iommu_kfree(struct iommu *obj, u32 da);
+extern struct sg_table *iommu_vunmap(struct iommu_domain *domain,
+ struct iommu *obj, u32 da);
+extern u32 iommu_vmalloc(struct iommu_domain *domain, struct iommu *obj,
+ u32 da, size_t bytes, u32 flags);
+extern void iommu_vfree(struct iommu_domain *domain, struct iommu *obj,
+ const u32 da);
+extern u32 iommu_kmap(struct iommu_domain *domain, struct iommu *obj, u32 da,
+ u32 pa, size_t bytes, u32 flags);
+extern void iommu_kunmap(struct iommu_domain *domain, struct iommu *obj,
+ u32 da);
+extern u32 iommu_kmalloc(struct iommu_domain *domain, struct iommu *obj,
+ u32 da, size_t bytes, u32 flags);
+extern void iommu_kfree(struct iommu_domain *domain, struct iommu *obj, u32
da);
extern void *da_to_va(struct iommu *obj, u32 da);
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 51ef43e..80bb2b6 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -15,6 +15,7 @@
#include linux/vmalloc.h
#include linux/device.h
#include linux/scatterlist.h
+#include linux/iommu.h
#include asm/cacheflush.h
#include asm/mach/map.h
@@ -456,15 +457,16 @@ static inline void sgtable_drain_kmalloc(struct sg_table
*sgt)
}
/* create 'da' - 'pa' mapping from 'sgt' */
-static int map_iovm_area(struct iommu *obj, struct iovm_struct *new,
-const struct sg_table *sgt, u32 flags)
+static int map_iovm_area(struct iommu_domain *domain, struct iovm_struct *new,
+ const struct sg_table *sgt, u32 flags)
{
int err;
unsigned int i, j;
struct scatterlist *sg;
u32 da = new-da_start;
+ int order;
- if (!obj || !sgt)
+ if (!domain || !sgt)
return -EINVAL;
BUG_ON(!sgtable_ok(sgt));
@@ -473,22 +475,22 @@ static int map_iovm_area(struct iommu *obj, struct
iovm_struct *new,
u32 pa;
int pgsz;
size_t bytes;
- struct iotlb_entry e;
pa = sg_phys(sg);
bytes = sg_dma_len(sg);
flags = ~IOVMF_PGSZ_MASK;
+
pgsz = bytes_to_iopgsz(bytes);
if (pgsz 0)
goto err_out;
- flags |= pgsz;
+
+ order = get_order(bytes);
pr_debug(%s: [%d] %08x %08x(%x)\n, __func__,
i, da, pa, bytes);
- iotlb_init_entry(e, da, pa, flags);
- err = iopgtable_store_entry(obj, e);
+ err = iommu_map(domain, da, pa, order, flags);
if (err)
goto err_out;
@@ -502,9 +504,11 @@ err_out:
for_each_sg(sgt-sgl, sg, i, j) {
size_t
Re: [PATCH] media: omap3isp: fix a pontential NULL deref
Hi Ohad,
On Wednesday 01 June 2011 18:39:46 Ohad Ben-Cohen wrote:
Fix a potential NULL pointer dereference by skipping registration of
external entities in case none are provided.
This is useful at least when testing mere memory-to-memory scenarios.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Applied, thanks.
---
drivers/media/video/omap3isp/isp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c index 2a5fbe6..367ced3 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -1756,7 +1756,7 @@ static int isp_register_entities(struct isp_device
*isp) goto done;
/* Register external entities */
- for (subdevs = pdata-subdevs; subdevs-subdevs; ++subdevs) {
+ for (subdevs = pdata-subdevs; subdevs subdevs-subdevs; ++subdevs) {
struct v4l2_subdev *sensor;
struct media_entity *input;
unsigned int flags;
--
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 0/6] iommu: generic api migration and grouping
Hi,
Good approach.
CC'ed the Samsung IOMMU developer. Marek.
BTW, Russell wants to use the DMA based IOMMU?
Please see the RFC patch, ARM: DMA-mapping IOMMU integration
http://www.spinics.net/lists/linux-mm/msg19856.html
Thank you,
Kyungmin Park
On Fri, Jun 3, 2011 at 7:27 AM, Ohad Ben-Cohen o...@wizery.com wrote:
First stab at iommu consolidation:
- Migrate OMAP's iommu driver to the generic iommu API. With this in hand,
users can now start using the generic iommu layer instead of calling
omap-specific iommu API.
New code that requires functionality missing from the generic iommu api,
will add that functionality in the generic framework (e.g. adding framework
awareness to multi page sizes, supported by the underlying hardware, will
avoid the otherwise-inevitable code duplication when mapping a memory
region).
OMAP-specific api that is still exposed in the omap iommu driver can
now be either moved to the generic iommu framework, or just removed (if not
used).
This api (and other omap-specific primitives like struct iommu) needs to
be omapified (i.e. renamed to include an 'omap_' prefix). At this early
point of this patch set this is too much churn though, so I'll do that
in the following iteration, after (and if), the general direction is
accepted.
- Migrate OMAP's iovmm (virtual memory manager) driver to the generic
iommu API. With this in hand, iovmm no longer uses omap-specific api
for mapping/unmapping operations. Nevertheless, iovmm is still coupled
with omap's iommu even with this change: it assumes omap page sizes,
and it uses omap's iommu objects to maintain its internal state.
Further generalizing of iovmm strongly depends on our broader plans for
providing a generic virtual memory manager and allocation framework
(which, as discussed, should be separated from a specific mapper).
iovmm has a mainline user: omap3isp, and therefore must be maintained,
but new potential users will either have to generalize it, or come up
with a different generic framework that will replace it.
- Migrate OMAP's iommu mainline user, omap3isp, to the generic API as well
(so it doesn't break). As with iovmm, omap3isp still depends on
omap's iommu, mainly because iovmm depends on it, but also for
iommu context saving and restoring.
It is definitely desirable to completely remove omap3isp's dependency
on the omap-specific iommu layer, and that will be possible as the
required functionality will be added to generic framework.
- Create a dedicated iommu drivers folder (and put the base iommu code there)
- Move OMAP's and MSM's iommu drivers to that drivers iommu folder
Putting all iommu drivers together will ease finding similarities
between different platforms, with the intention of solving problems once,
in a generic framework which everyone can use.
I've only moved the omap and msm implementations for now, to demonstrate
the idea (and support the ARM diet :), but if this is found desirable,
we can bring in intel-iommu.c and amd_iommu.c as well.
Meta:
- This patch set is not bisectable; it was splitted (and ordered) this way
to ease its review. Later iterations of this patch set will fix that
(most likely by squashing the first three patches)
- Based on and tested with 3.0-rc1
- OMAP's iommu code was tested on both OMAP3 and OMAP4
- omap3isp code was tested with a sensor-less OMAP3 (memory-to-memory only)
(thanks Laurent Pinchart for showing me the magic needed to test omap3isp :)
- MSM code was only compile tested
Ohad Ben-Cohen (6):
omap: iommu: generic iommu api migration
omap: iovmm: generic iommu api migration
media: omap3isp: generic iommu api migration
drivers: iommu: move to a dedicated folder
omap: iommu/iovmm: move to dedicated iommu folder
msm: iommu: move to dedicated iommu drivers folder
arch/arm/mach-msm/Kconfig | 15 -
arch/arm/mach-msm/Makefile | 2 +-
arch/arm/plat-omap/Kconfig | 12 -
arch/arm/plat-omap/Makefile | 2 -
arch/arm/plat-omap/include/plat/iommu.h | 3 +-
arch/arm/plat-omap/{ = include/plat}/iopgtable.h | 18 ++
arch/arm/plat-omap/include/plat/iovmm.h | 27 +-
arch/x86/Kconfig | 5 +-
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/base/Makefile | 1 -
drivers/iommu/Kconfig | 32 +++
drivers/iommu/Makefile | 5 +
drivers/{base = iommu}/iommu.c | 0
.../mach-msm/iommu.c = drivers/iommu/msm-iommu.c | 0
.../iommu/omap-iommu-debug.c | 2 +-
.../iommu.c = drivers/iommu/omap-iommu.c | 290
+---
.../iovmm.c = drivers/iommu/omap-iovmm.c
Re: Does omap3isp driver inherit controls of attached sensors?
Hi Javier, On Thursday 02 June 2011 15:52:57 javier Martin wrote: Hi, I'm trying to add VFLIP control to the mt9p031 driver (don't worry Guennadi, I won't send the patch yet). For that purpose I've followed the code in mt9v032 sensor. When I try to query available controls using yavta I get the following: root@beagleboard:~# ./media-ctl -e OMAP3 ISP CCDC output /dev/video2 root@beagleboard:~# ./yavta -l /dev/video2 Device /dev/video2 opened: OMAP3 ISP CCDC output (media). No control found. As I have read here [1], drivers using subdevices should inherit their controls. Is this the case with omap3isp? No, the OMAP3 ISP video nodes don't inherit subdev controls. You need to access the control directly on the sensor subdev. [1] http://lxr.linux.no/#linux+v2.6.39/Documentation/video4linux/v4l2-controls .txt -- 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: [linux-dvb] XC4000 patches for kernel 2.6.37.2
On Thu, 02 Jun 2011 11:41:53 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em 02-06-2011 07:52, Devin Heitmueller escreveu: 2011/5/31 Dmitri Belimov d.beli...@gmail.com: Is it possible make some patches and add support xc4000 into kernel? With my best regards, Dmitry. What needs to happen here is somebody needs to prepare a patch series which contains all the relevant patches, including the SOBs. This is entirely an janitorial task which can be done by anyone and frankly I don't have time for this sort of crap anymore. Any volunteers? All my patches have my SOB attached. I explicitly got Davide's permission to add his SOB to his original patch, but it's not in the HG tree since I got the permission after I committed his change to my repo. I can forward the email with his SOB so the person constructing the tree can add it on (as well as my SOB to preserve the chain of custody). Secondly, we need to build a firmware image which is based off of the *actual* xceive firmware sources, so that we can be confident that all the blobs are from the same firmware revision and so that we can maintain them going forward. I can provide them off-list to someone willing to do this work and testing. Istann_v's firmware image is based off of i2c dumps and extracted by hand from disassembled firmware, which is less than ideal from an ongoing maintenance perspective. And of course it's worth mentioning that the driver itself still needs a ton of cleanup, doesn't meet the coding standards, and wouldn't be accepted upstream in its current state. Somebody will need to do the work to clean up the driver, as well as testing to make sure he/she didn't cause any regressions. In summary, here are the four things that need to happen: 1. Assemble tree with current patches It is probably easier for me to do this step, as I have my hg import scripts. However, as I don't have the PCTV devices added at dib0700, I can't test. OK, I did this work, as it just took me a few minutes to rebase patches 1 and 2. I didn't apply the patches that started with djh since they seemed to be a few hacks during the development time. The tree is at: git://linuxtv.org/mchehab/experimental.git branch xc4000 There are two warnings there that needs to be fixed: drivers/media/common/tuners/xc4000.c:1293: warning: ‘xc4000_is_firmware_loaded’ defined but not used drivers/media/common/tuners/xc4000.c: In function ‘check_firmware.clone.0’: drivers/media/common/tuners/xc4000.c:1107: warning: ‘version’ may be used uninitialized in this function Both seems to be trivial. A disclaimer notice here: I didn't make any cleanup at the code, (except by running a whitespace cleanup script) nor I've reviewed it. IMO, the next step is to test the rebases against a real hardware, and adding a few patches fixing it, if the rebases broke. The next step would be fix the CodingStyle, and run checkpatch.pl. There aren't many CodingStyle warnings/errors (13 errors, 28 warnings). Most of the errors are due to the excess usage of printk's for debug, and due to some obsolete code commented with //. 2. Construct valid firmware image off of current sources 3. Cleanup/coding style 4. Testing Now that we've got a bunch of people who are interested in seeing this upstream, who is going to volunteer to do which items in the above list? Devin One of our TV card has this tuner. It works in analog mode. I try get right firmware cleanup and test. Can I use git://linuxtv.org/mchehab/experimental.git branch xc4000 for do it? With my best regards, Dmitry. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MAINTAINERS: Add videobuf2 maintainers
On Thu, Jun 2, 2011 at 00:52, Marek Szyprowski m.szyprow...@samsung.com wrote: Add maintainers for the videobuf2 V4L2 driver framework. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- MAINTAINERS | 9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 29801f7..63be58b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6720,6 +6720,15 @@ S: Maintained F: Documentation/filesystems/vfat.txt F: fs/fat/ +VIDEOBUF2 FRAMEWORK +M: Pawel Osciak pa...@osciak.com +M: Marek Szyprowski m.szyprow...@samsung.com +M: Kyungmin Park kyungmin.p...@samsung.com +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/media/video/videobuf2-* +F: include/media/videobuf2-* + VIRTIO CONSOLE DRIVER M: Amit Shah amit.s...@redhat.com L: virtualizat...@lists.linux-foundation.org -- 1.7.1.569.g6f426 Signed-off-by: Pawel Osciak pa...@osciak.com -- Best regards, Pawel Osciak -- 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: [linux-dvb] XC4000 patches for kernel 2.6.37.2
Thank you for the comments and pointers. I am happy, at least there are peoples who want to see the xc4000 driver alive. On 2011-06-02, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 02-06-2011 12:53, Mohammad Bahathir Hashim escreveu: Now I understood how thing works here, and it clear to me, why the xc4000 driver is not being included in mainline V4L2. It will be lots of commitments and hard work to be the maintainer, and I respect Mr. Devin's choice and decisions. There are several peoples that are interested in this driver, such as Mr. Istvan. I realized this driver does not have huge users/audiences, but still there are peoples who really need it. But, yeah, not everybody can 'port' the driver each time Linux kernel or V4L2 version being updated. In this case, IF no one is able to maintains the driver, how others can benefit the 'updated' driver or patches for the new V4L2 or Linux releases? Out of tree drivers tend to become obsolete on a few kernel releases, as the internal kernel API's were not designed to be stable, as we want innovation inside the kernel. So, people are free to change the internal APIs when needed. That's why the best way is to submit patches upstream as they're ready for it. At the moment I still be able to port and test it for my private use. Sometime I sent the patches to Mr. Istvan to be included in his xc4000 driver's website, for other users to use it. BTW, I am not a programmer. I am just a system administrator, who only like to use shell scripts, awk, sed and grep. I only know how 'read' C, and can do SIMPLE 'porting' and testing tasks :). Still I really hope other developers able to include the analog TV/FM tuning and S-Video input feature to PCTV-340e. Anyway, if this driver is not elligible to be included in V4L2 mainline, I know where to 'push' my patches. :) Almost all drivers are eligible to be included, but the author needs to submit them, or someone on their behalf. If the driver doesn't have enough quality or needs some fixes, the submitter may need to fix it or, eventually, move it to staging. With respect to xc4000, we need someone to test if the driver works after the backports. Please test it and answer to us with a Tested-by tag. After the tests, it would be great to apply any pending patches for xc4000 before cleaning it, as if we do the reverse, existing patches won't apply. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Anchor Chips V4L2 driver
I'd like to write a driver for an Anchor Chips (seems to be bought by Cypress) USB camera Linux driver sold as an AmScope MD1800. It seems like this implies I need to write a V4L2 driver. The camera does not seem its currently supported (checked on Fedora 13 / 2.6.34.8) and I did not find any information on it in mailing list archives. Does anyone know or can help me identify if a similar camera might already be supported? lsusb gives the following output: Bus 001 Device 111: ID 0547:4d88 Anchor Chips, Inc. I've started reading the Video for Linux Two API Specification which seems like a good starting point and will move onto using source code as appropriate. Any help would be appreciated. Thanks! John -- 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
