Re: Results of the 'dropping support for kernels 2.6.22' poll
On Tue, 3 Mar 2009, Hans Verkuil wrote: On Monday 02 March 2009 23:47:31 Trent Piepho wrote: On Mon, 2 Mar 2009, Hans Verkuil wrote: There are good reasons as a developer for keeping backwards compatibility with older kernels: Do you mean no backwards compatibility with any older kernels? Or do you mean just dropping support for the oldest kernels now supported. What you've said above sounds like the former. This was about the advantages of having compat code at all to support kernels other than the bleeding edge git kernel. I thought the poll was only about dropping support for kernels older than 2.6.22? Will you allow drivers to use a combination of probe based and detect based i2c using the new i2c api? It's my understanding that you only support the new i2c api for probe-only drivers. Probe/detect or ever detect-only drivers for the new i2c api haven't been done? I think much of the difficulty of supporting 2.6.22 will be solved once there is a way to allow drivers to use both probe and detect with the new api. The difficulties are not with probe or detect, but with the fact that with the new API the adapter driver has to initiate the probe instead of the autoprobing that happened in the past by just loading the i2c module. The That's not true. Using the new API's -probe() method works like you say, but using the new API's -detect() method is much more like the autoprobing that happened in the past. I don't think we have to use the detect() functionality at all in i2c modules, although I need to look at bttv more closely to see whether that is a true statement. I'm at this moment opposed to the use of detect() since I fear it can lead to pretty much the same problems as autoprobing does when you start to rely on it. It's meant for legacy code where proper device/address information is not present. In the case of v4l-dvb the only driver that might qualify is bttv. In some cases there is no way to identify the what hardware a card has and there is also new cards that are still unknown. I think I would have gone about it from the other side. Convert bttv to use detect and then make that backward compatible. That compatibility should be much easier and less invasive. This wouldn't have made any difference at all. But you said yourself that the difficulties are with the fact that with the new API the adapter driver has to initiate the probe instead of the autoprobing that happened in the past. Converting the bttv driver to use detect with the new API would avoid those difficulties. -- 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] ov772x: Add extra setting method
On Tue, 3 Mar 2009, Kuninori Morimoto wrote:
This patch add support extra register settings for platform.
For instance, platform comes to be able to use the
special setting like lens.
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
[snip]
@@ -815,6 +808,14 @@ static int ov772x_set_params(struct ov772x_priv *priv,
u32 width, u32 height,
*/
ov772x_reset(priv-client);
+ /* set extra setting */
+ if (priv-info-extra) {
+ ret = ov772x_write_array(priv-client,
+ priv-info-extra);
+ if (ret 0)
+ goto ov772x_set_fmt_error;
+ }
+
/*
* set size format
*/
Hm, cannot say this patch makes me specifically happy. This means we let
the user directly arbitrarily configure our registers. I don't seem to
have a datasheet for ov772x, so, I cannot judge what registers are
required for lens configuration, and how many meaningful settings there
can be. For instance, maybe there are only two variants like
lens-configuration-A and lens-configuration-B? Then I would just add
respective flags to platform data. If there are really many variants,
maybe we can let user-space configure them using VIDIOC_DBG_S_REGISTER?
Can you maybe explain to me at least approximately what those lens
settings are doing? Are there any sane defaults that would reasonably work
with all lenses? In the very worst case, if we decide - no, this is very
platform specific, and it has to be done in the kernel (why?), I would
prefer adding elements like
u32 LENS_CONFIG_1;
u32 LENS_CONFIG_2;
...
rather than allowing the platform to arbitrarily mangle our registers?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
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
[PULL] gspca
Hi Mauro, Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb/ for: changeset: 10769:f24deaa13550 gspca - mars: Bad webcam register values tied to saturation. changeset: 10770:cd642f9e485b gspca - vc032x: Bad matrix for sensor mi1310_soc. changeset: 10789:57bfe95f2ac1 gspca - most jpeg subdrivers: Change the JPEG header creation. changeset: 10790:2a1b8f88f331 gspca - most jpeg subdrivers: Have the JPEG quality settable. Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: General protection fault on rmmod cx8800
On Mon, 2 Mar 2009, Jean Delvare wrote: Makes the most sense to me. I was just about to make a patch to do the same thing when I got your email. Though I was going to patch the v4l-dvb sources to avoid porting work. It was easier for me to test on an upstream kernel. The porting should be fairly easy, I can take care of it. The difficult part will be to handle the compatibility with kernels 2.6.20 because delayed_work was introduced in 2.6.20. Probably compatibility here will simply mean that the bug I've hit will only be fixed for kernels = 2.6.20. Which once again raises the question of whether we really want to keep supporting these old kernels. cancel_delayed_work_sync() was renamed from cancel_rearming_delayed_work() in 2.6.23. A compat.h patch can handle that one. In 2.6.22, cancel_delayed_work_sync(work) was created from cancel_rearming_delayed_workqueue(wq, work). The kernel has a compat function to turn cancel_rearming_delayed_workqueue() into the cancel_delayed_work_sync() call. cancel_rearming_delayed_workqueue() has been around since 2.6.13. Apparently it was un-exported for a while because it had no users, see commit v2.6.12-rc2-8-g81ddef7. Isn't it nice that there a commit message other than export cancel_rearming_delayed_workqueue? Let me again express my dislike for commit with no description. In 2.6.20 delayed_work was split from work_struct. The concept of delayed work was already there and schedule_delayed_work() hasn't changed. I think this can also be handled with a compat.h change that defines delayed_work to work_struct. That will only be a problem on pre 2.6.20 kernels if some code decides to define identifiers named work_struct and delayed_work in the same scope. There are currently no identifier named delayed_work in any driver and one driver (sq905) has a structure member named work_struct. So I think it'll be ok. -- 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] ov772x: Add extra setting method
Dear Guennadi
can be. For instance, maybe there are only two variants like
lens-configuration-A and lens-configuration-B? Then I would just add
respective flags to platform data. If there are really many variants,
maybe we can let user-space configure them using VIDIOC_DBG_S_REGISTER?
Can you maybe explain to me at least approximately what those lens
settings are doing?
well... useing VIDIOC_DBG_S_REGISTER is not good idea for me.
Because we have to add CONFIG_VIDEO_ADY_DEBUG option which is for debug.
ap325 lens setting have
o a lot of common control register setting
o AGC/AEC/BLC/DSP/AWB setting
o Banding filter
o Y/G channel average value
o color value
a lot of register will be set.
like this
+static const struct regval_list ov7725_lens [] = {
+ { 0x09, 0x00 }, { 0x0D, 0x61 }, { 0x0E, 0xD5 }, { 0x0F, 0xC5 },
+ { 0x10, 0x25 }, { 0x11, 0x01 }, { 0x13, 0xEF }, { 0x14, 0x41 },
+ { 0x22, 0x7F }, { 0x23, 0x03 }, { 0x24, 0x40 }, { 0x25, 0x30 },
+ { 0x26, 0x82 }, { 0x2F, 0x35 }, { 0x37, 0x81 }, { 0x39, 0x6C },
+ { 0x3A, 0x8C }, { 0x3B, 0xBC }, { 0x3C, 0xC0 }, { 0x3D, 0x03 },
+ { 0x40, 0xE8 }, { 0x41, 0x00 }, { 0x42, 0x7F }, { 0x49, 0x00 },
+ { 0x4A, 0x00 }, { 0x4B, 0x00 }, { 0x4C, 0x00 }, { 0x4D, 0x09 },
+ { 0x60, 0x00 }, { 0x61, 0x05 }, { 0x63, 0xE0 }, { 0x64, 0xFF },
+ { 0x65, 0x20 }, { 0x66, 0x00 }, { 0x69, 0x9E }, { 0x6B, 0x2D },
+ { 0x6C, 0x09 }, { 0x6E, 0x72 }, { 0x6F, 0x4D }, { 0x70, 0x12 },
+ { 0x71, 0xBF }, { 0x72, 0x0D }, { 0x73, 0x12 }, { 0x74, 0x12 },
+ { 0x76, 0x00 }, { 0x77, 0x3A }, { 0x78, 0x23 }, { 0x79, 0x22 },
+ { 0x7A, 0x41 }, { 0x7E, 0x04 }, { 0x7F, 0x0E }, { 0x80, 0x20 },
+ { 0x81, 0x43 }, { 0x82, 0x53 }, { 0x83, 0x61 }, { 0x84, 0x6D },
+ { 0x85, 0x76 }, { 0x86, 0x7E }, { 0x87, 0x86 }, { 0x88, 0x94 },
+ { 0x89, 0xA1 }, { 0x8A, 0xC5 }, { 0x8E, 0x03 }, { 0x8F, 0x02 },
+ { 0x90, 0x05 }, { 0x91, 0x01 }, { 0x92, 0x03 }, { 0x93, 0x00 },
+ { 0x94, 0x7A }, { 0x95, 0x75 }, { 0x96, 0x05 }, { 0x97, 0x22 },
+ { 0x98, 0x63 }, { 0x99, 0x85 }, { 0x9A, 0x1E }, { 0x9B, 0x08 },
+ { 0x9C, 0x20 }, { 0x9E, 0x00 }, { 0x9F, 0xF8 }, { 0xA0, 0x02 },
+ { 0xA1, 0x50 }, { 0xA6, 0x04 }, { 0xA7, 0x30 }, { 0xA8, 0x30 },
+ { 0xAA, 0x00 }, ENDMARKER,
+};
Best regards
--
Kuninori Morimoto
--
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/9] OMAP3 ISP and camera drivers
Hi, So here's the patchset for OMAP 3 ISP and camera drivers plus the associated V4L changes. Sergio Aguirre has been posting a related patchset earlier, containing also sensor and lens driver used on SDP. This patchset is agains the linux-omap tree: URL:http://www.muru.com/linux/omap/README_OMAP_GIT So I and Sergio have synchronised our versions of the ISP and camera drivers and this is the end result. There is still a lot of work to do, though. You can find some comments in individual patch descriptions. If the todo list for a patch is empty it doesn't mean there wouldn't be anything left to do. ;) There's at least one major change to Sergio Aguirre's earlier patches which is that the ISP driver now uses the IOMMU from Hiroshi Doyu. Hiroshi is away for some time now so there are just some hacks on top of Hiroshi's older iommu patches to use with current linux-omap. This patchset does not contain the resizer or preview wrappers from TI but they have been left intentionally out. A proper interface (V4L) should be used for those and the camera driver should be somehow involved --- the wrappers are just duplicating much of the camera driver's functionality. I don't have any sensor or lens drivers to publish at this time. This patchset should work with the SDP and OMAPZoom boards although you need the associated sensor drivers + the board code from Sergio Aguirre to use it. You'll also need the IOMMU patchset from Hiroshi Doyu. Everything except the sensor / board stuff is available here: URL:http://www.gitorious.org/projects/omap3camera In short, on linux-omap: $ git pull http://git.gitorious.org/omap3camera/mainline.git v4l \ iommu omap3camera base Hiroshi's original iommu tree is here (branch iommu): URL:http://git.gitorious.org/lk/mainline.git Some of the camera and ISP driver development history is available, too. See the first link. Any feedback is appreciated. Sincerely, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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 4/9] omap3isp: Add ISP frontend (CCDC)
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/isp/ispccdc.c | 1568 +
drivers/media/video/isp/ispccdc.h | 203 +
2 files changed, 1771 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/isp/ispccdc.c
create mode 100644 drivers/media/video/isp/ispccdc.h
diff --git a/drivers/media/video/isp/ispccdc.c
b/drivers/media/video/isp/ispccdc.c
new file mode 100644
index 000..80ab762
--- /dev/null
+++ b/drivers/media/video/isp/ispccdc.c
@@ -0,0 +1,1568 @@
+/*
+ * ispccdc.c
+ *
+ * Driver Library for CCDC module in TI's OMAP3 Camera ISP
+ *
+ * Copyright (C) 2009 Texas Instruments, Inc.
+ *
+ * Contributors:
+ * Senthilvadivu Guruswamy svad...@ti.com
+ * Pallavi Kulkarni p-kulka...@ti.com
+ * Sergio Aguirre saagui...@ti.com
+ *
+ * This package is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+#include linux/mutex.h
+#include linux/module.h
+#include linux/uaccess.h
+
+#include isp.h
+#include ispreg.h
+#include ispccdc.h
+#include ispmmu.h
+
+#define LSC_TABLE_INIT_SIZE50052
+
+static u32 *fpc_table_add;
+static unsigned long fpc_table_add_m;
+
+/**
+ * struct isp_ccdc - Structure for the CCDC module to store its own information
+ * @ccdc_inuse: Flag to determine if CCDC has been reserved or not (0 or 1).
+ * @ccdcout_w: CCDC output width.
+ * @ccdcout_h: CCDC output height.
+ * @ccdcin_w: CCDC input width.
+ * @ccdcin_h: CCDC input height.
+ * @ccdcin_woffset: CCDC input horizontal offset.
+ * @ccdcin_hoffset: CCDC input vertical offset.
+ * @crop_w: Crop width.
+ * @crop_h: Crop weight.
+ * @ccdc_inpfmt: CCDC input format.
+ * @ccdc_outfmt: CCDC output format.
+ * @vpout_en: Video port output enable.
+ * @wen: Data write enable.
+ * @exwen: External data write enable.
+ * @refmt_en: Reformatter enable.
+ * @ccdcslave: CCDC slave mode enable.
+ * @syncif_ipmod: Image
+ * @obclamp_en: Data input format.
+ * @mutexlock: Mutex used to get access to the CCDC.
+ */
+static struct isp_ccdc {
+ u8 ccdc_inuse;
+ u32 ccdcout_w;
+ u32 ccdcout_h;
+ u32 ccdcin_w;
+ u32 ccdcin_h;
+ u32 ccdcin_woffset;
+ u32 ccdcin_hoffset;
+ u32 crop_w;
+ u32 crop_h;
+ u8 ccdc_inpfmt;
+ u8 ccdc_outfmt;
+ u8 vpout_en;
+ u8 wen;
+ u8 exwen;
+ u8 refmt_en;
+ u8 ccdcslave;
+ u8 syncif_ipmod;
+ u8 obclamp_en;
+ u8 lsc_en;
+ struct mutex mutexlock; /* For checking/modifying ccdc_inuse */
+ u32 wenlog;
+} ispccdc_obj;
+
+static struct ispccdc_lsc_config lsc_config;
+static u8 *lsc_gain_table;
+static unsigned long lsc_ispmmu_addr;
+static int lsc_initialized;
+static u8 ccdc_use_lsc;
+static u8 *lsc_gain_table_tmp;
+
+/* Structure for saving/restoring CCDC module registers*/
+static struct isp_reg ispccdc_reg_list[] = {
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_HD_VD_WID, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_PIX_LINES, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_HORZ_INFO, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_START, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_LINES, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_CULLING, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_HSIZE_OFF, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDR_ADDR, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_CLAMP, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_DCSUB, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_COLPTN, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_BLKCMP, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FPC, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FPC_ADDR, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_ALAW, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_REC656IF, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_CFG, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMTCFG, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_HORZ, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_VERT, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_ADDR0, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_ADDR1, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_ADDR2, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_ADDR3, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_ADDR4, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_ADDR5, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_ADDR6, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_ADDR7, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_PRGEVEN0, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_PRGEVEN1, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_PRGODD0,
[PATCH 3/9] omap3isp: Add userspace header
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
arch/arm/plat-omap/include/mach/isp_user.h | 676
1 files changed, 676 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/mach/isp_user.h
diff --git a/arch/arm/plat-omap/include/mach/isp_user.h
b/arch/arm/plat-omap/include/mach/isp_user.h
new file mode 100644
index 000..b819e26
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/isp_user.h
@@ -0,0 +1,676 @@
+/*
+ * isp_user.h
+ *
+ * Include file for OMAP ISP module in TI's OMAP3.
+ *
+ * Copyright (C) 2009 Texas Instruments, Inc.
+ *
+ * Contributors:
+ * Mohit Jalori mjal...@ti.com
+ * Sergio Aguirre saagui...@ti.com
+ *
+ * This package is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+#ifndef OMAP_ISP_USER_H
+#define OMAP_ISP_USER_H
+
+/* ISP Private IOCTLs */
+#define VIDIOC_PRIVATE_ISP_CCDC_CFG\
+ _IOWR('V', BASE_VIDIOC_PRIVATE + 1, struct ispccdc_update_config)
+#define VIDIOC_PRIVATE_ISP_PRV_CFG \
+ _IOWR('V', BASE_VIDIOC_PRIVATE + 2, struct ispprv_update_config)
+#define VIDIOC_PRIVATE_ISP_AEWB_CFG \
+ _IOWR('V', BASE_VIDIOC_PRIVATE + 4, struct isph3a_aewb_config)
+#define VIDIOC_PRIVATE_ISP_AEWB_REQ \
+ _IOWR('V', BASE_VIDIOC_PRIVATE + 5, struct isph3a_aewb_data)
+#define VIDIOC_PRIVATE_ISP_HIST_CFG \
+ _IOWR('V', BASE_VIDIOC_PRIVATE + 6, struct isp_hist_config)
+#define VIDIOC_PRIVATE_ISP_HIST_REQ \
+ _IOWR('V', BASE_VIDIOC_PRIVATE + 7, struct isp_hist_data)
+#define VIDIOC_PRIVATE_ISP_AF_CFG \
+ _IOWR('V', BASE_VIDIOC_PRIVATE + 8, struct af_configuration)
+#define VIDIOC_PRIVATE_ISP_AF_REQ \
+ _IOWR('V', BASE_VIDIOC_PRIVATE + 9, struct isp_af_data)
+
+/* AE/AWB related structures and flags*/
+
+/* Flags for update field */
+#define REQUEST_STATISTICS (1 0)
+#define SET_COLOR_GAINS(1 1)
+#define SET_DIGITAL_GAIN (1 2)
+#define SET_EXPOSURE (1 3)
+#define SET_ANALOG_GAIN(1 4)
+
+#define MAX_FRAME_COUNT0x0FFF
+#define MAX_FUTURE_FRAMES 10
+
+#define MAX_SATURATION_LIM 1023
+#define MIN_WIN_H 2
+#define MAX_WIN_H 256
+#define MIN_WIN_W 6
+#define MAX_WIN_W 256
+#define MAX_WINVC 128
+#define MAX_WINHC 36
+#define MAX_WINSTART 4095
+#define MIN_SUB_INC2
+#define MAX_SUB_INC32
+
+/* Range Constants */
+#define AF_IIRSH_MIN 0
+#define AF_IIRSH_MAX 4094
+#define AF_PAXEL_HORIZONTAL_COUNT_MIN 0
+#define AF_PAXEL_HORIZONTAL_COUNT_MAX 35
+#define AF_PAXEL_VERTICAL_COUNT_MIN0
+#define AF_PAXEL_VERTICAL_COUNT_MAX127
+#define AF_PAXEL_INCREMENT_MIN 0
+#define AF_PAXEL_INCREMENT_MAX 14
+#define AF_PAXEL_HEIGHT_MIN0
+#define AF_PAXEL_HEIGHT_MAX127
+#define AF_PAXEL_WIDTH_MIN 0
+#define AF_PAXEL_WIDTH_MAX 127
+#define AF_PAXEL_HZSTART_MIN 2
+#define AF_PAXEL_HZSTART_MAX 4094
+
+#define AF_PAXEL_VTSTART_MIN 0
+#define AF_PAXEL_VTSTART_MAX 4095
+#define AF_THRESHOLD_MAX 255
+#define AF_COEF_MAX4095
+#define AF_PAXEL_SIZE 48
+
+/**
+ * struct isph3a_aewb_config - AE AWB configuration reset values.
+ * saturation_limit: Saturation limit.
+ * @win_height: Window Height. Range 2 - 256, even values only.
+ * @win_width: Window Width. Range 6 - 256, even values only.
+ * @ver_win_count: Vertical Window Count. Range 1 - 128.
+ * @hor_win_count: Horizontal Window Count. Range 1 - 36.
+ * @ver_win_start: Vertical Window Start. Range 0 - 4095.
+ * @hor_win_start: Horizontal Window Start. Range 0 - 4095.
+ * @blk_ver_win_start: Black Vertical Windows Start. Range 0 - 4095.
+ * @blk_win_height: Black Window Height. Range 2 - 256, even values only.
+ * @subsample_ver_inc: Subsample Vertical points increment Range 2 - 32, even
+ * values only.
+ * @subsample_hor_inc: Subsample Horizontal points increment Range 2 - 32, even
+ * values only.
+ * @alaw_enable: AEW ALAW EN flag.
+ * @aewb_enable: AE AWB stats generation EN flag.
+ */
+struct isph3a_aewb_config {
+ __u16 saturation_limit;
+ __u16 win_height;
+ __u16 win_width;
+ __u16 ver_win_count;
+ __u16 hor_win_count;
+ __u16 ver_win_start;
+ __u16 hor_win_start;
+ __u16 blk_ver_win_start;
+ __u16 blk_win_height;
+ __u16 subsample_ver_inc;
+ __u16 subsample_hor_inc;
+ __u8 alaw_enable;
+ __u8
[PATCH 8/9] omap3isp: Add ISP tables
* Blue Gamma gain table * CFA gain table * Green Gamma gain table * Luma Enhancement gain table * Noise filter gain table * Red Gamma gain table TODO: - Get rid of this kind of tables. Either generate them at runtime or use a user space program to fill defaults. Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com --- drivers/media/video/isp/bluegamma_table.h| 1040 ++ drivers/media/video/isp/cfa_coef_table.h | 603 +++ drivers/media/video/isp/greengamma_table.h | 1040 ++ drivers/media/video/isp/luma_enhance_table.h | 144 drivers/media/video/isp/noise_filter_table.h | 79 ++ drivers/media/video/isp/redgamma_table.h | 1040 ++ 6 files changed, 3946 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/isp/bluegamma_table.h create mode 100644 drivers/media/video/isp/cfa_coef_table.h create mode 100644 drivers/media/video/isp/greengamma_table.h create mode 100644 drivers/media/video/isp/luma_enhance_table.h create mode 100644 drivers/media/video/isp/noise_filter_table.h create mode 100644 drivers/media/video/isp/redgamma_table.h diff --git a/drivers/media/video/isp/bluegamma_table.h b/drivers/media/video/isp/bluegamma_table.h new file mode 100644 index 000..301382a --- /dev/null +++ b/drivers/media/video/isp/bluegamma_table.h @@ -0,0 +1,1040 @@ +/* + * bluegamma_table.h + * + * Gamma Table values for BLUE for TI's OMAP3 Camera ISP + * + * Copyright (C) 2009 Texas Instruments, Inc. + * + * This package is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. + */ + +0, +0, +1, +2, +3, +3, +4, +5, +6, +8, +10, +12, +14, +16, +18, +20, +22, +23, +25, +26, +28, +29, +31, +32, +34, +35, +36, +37, +39, +40, +41, +42, +43, +44, +45, +46, +47, +48, +49, +50, +51, +52, +52, +53, +54, +55, +56, +57, +58, +59, +60, +61, +62, +63, +63, +64, +65, +66, +66, +67, +68, +69, +69, +70, +71, +72, +72, +73, +74, +75, +75, +76, +77, +78, +78, +79, +80, +81, +81, +82, +83, +84, +84, +85, +86, +87, +88, +88, +89, +90, +91, +91, +92, +93, +94, +94, +95, +96, +97, +97, +98, +98, +99, +99, +100, +100, +101, +101, +102, +103, +104, +104, +105, +106, +107, +108, +108, +109, +110, +111, +111, +112, +113, +114, +114, +115, +116, +117, +117, +118, +119, +119, +120, +120, +121, +121, +122, +122, +123, +123, +124, +124, +125, +125, +126, +126, +127, +127, +128, +128, +129, +129, +130, +130, +131, +131, +132, +132, +133, +133, +134, +134, +135, +135, +136, +136, +137, +137, +138, +138, +139, +139, +140, +140, +141, +141, +142, +142, +143, +143, +144, +144, +145, +145, +146, +146, +147, +147, +148, +148, +149, +149, +150, +150, +151, +151, +152, +152, +153, +153, +153, +153, +154, +154, +154, +154, +155, +155, +156, +156, +157, +157, +158, +158, +158, +159, +159, +159, +160, +160, +160, +161, +161, +162, +162, +163, +163, +164, +164, +164, +164, +165, +165, +165, +165, +166, +166, +167, +167, +168, +168, +169, +169, +170, +170, +170, +170, +171, +171, +171, +171, +172, +172, +173, +173, +174, +174, +175, +175, +176, +176, +176, +176, +177, +177, +177, +177, +178, +178, +178, +178, +179, +179, +179, +179, +180, +180, +180, +180, +181, +181, +181, +181, +182, +182, +182, +182, +183, +183, +183, +183, +184, +184, +184, +184, +185, +185, +185, +185, +186, +186, +186, +186, +187, +187, +187, +187, +188, +188, +188, +188, +189, +189, +189, +189, +190, +190, +190, +190, +191, +191, +191, +191, +192, +192, +192, +192, +193, +193, +193, +193, +194, +194, +194, +194, +195, +195, +195, +195, +196, +196, +196, +196, +197, +197, +197, +197, +198, +198, +198, +198, +199, +199, +199, +199, +200, +200, +200, +200, +201, +201, +201, +201, +202, +202, +202, +203, +203, +203, +203, +204, +204, +204, +204, +205, +205, +205, +205, +206, +206, +206, +206, +207, +207, +207, +207, +208, +208, +208, +208, +209, +209, +209, +209, +210, +210, +210, +210, +210, +210, +210, +210, +210, +210, +210, +210, +211, +211, +211, +211, +211, +211, +211, +211, +211, +211, +211, +212, +212, +212, +212, +213, +213, +213, +213, +213, +213, +213, +213, +213, +213, +213, +213, +214, +214, +214, +214, +215, +215, +215, +215, +215, +215, +215, +215, +215, +215, +215, +216, +216, +216, +216, +217, +217, +217, +217, +218, +218, +218, +218, +219, +219, +219, +219, +219, +219, +219, +219, +219, +219, +219, +219, +220, +220, +220, +220, +221, +221, +221, +221, +221, +221, +221, +221, +221, +221, +221, +222, +222, +222, +222, +223, +223, +223, +223, +223, +223, +223, +223, +223, +223, +223, +223, +224, +224, +224, +224, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225,
[PATCH 2/9] omap3isp: Add ISP MMU wrapper
TODO:
- The ISP driver should start using the IOMMU directly without this wrapper.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/isp/ispmmu.c | 141 ++
drivers/media/video/isp/ispmmu.h | 36 ++
2 files changed, 177 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/isp/ispmmu.c
create mode 100644 drivers/media/video/isp/ispmmu.h
diff --git a/drivers/media/video/isp/ispmmu.c b/drivers/media/video/isp/ispmmu.c
new file mode 100644
index 000..f872c71
--- /dev/null
+++ b/drivers/media/video/isp/ispmmu.c
@@ -0,0 +1,141 @@
+/*
+ * omap iommu wrapper for TI's OMAP3430 Camera ISP
+ *
+ * Copyright (C) 2008--2009 Nokia.
+ *
+ * Contributors:
+ * Hiroshi Doyu hiroshi.d...@nokia.com
+ * Sakari Ailus sakari.ai...@nokia.com
+ *
+ * This package is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+#include linux/module.h
+
+#include ispmmu.h
+#include isp.h
+
+#include mach/iommu.h
+#include mach/iovmm.h
+
+#define IOMMU_FLAG (IOVMF_ENDIAN_LITTLE | IOVMF_ELSZ_8)
+
+static struct iommu *isp_iommu;
+
+dma_addr_t ispmmu_vmalloc(size_t bytes)
+{
+ return (dma_addr_t)iommu_vmalloc(isp_iommu, 0, bytes, IOMMU_FLAG);
+}
+
+void ispmmu_vfree(const dma_addr_t da)
+{
+ iommu_vfree(isp_iommu, (u32)da);
+}
+
+dma_addr_t ispmmu_kmap(u32 pa, int size)
+{
+ void *da;
+
+ da = (void *)iommu_kmap(isp_iommu, 0, pa, size, IOMMU_FLAG);
+ if (IS_ERR(da))
+ return PTR_ERR(da);
+
+ return (dma_addr_t)da;
+}
+
+void ispmmu_kunmap(dma_addr_t da)
+{
+ iommu_kunmap(isp_iommu, (u32)da);
+}
+
+dma_addr_t ispmmu_vmap(const struct scatterlist *sglist,
+ int sglen)
+{
+ int err;
+ void *da;
+ struct sg_table *sgt;
+ unsigned int i;
+ struct scatterlist *sg, *src = (struct scatterlist *)sglist;
+
+ /*
+* convert isp sglist to iommu sgt
+* FIXME: should be fixed in the upper layer?
+*/
+ sgt = kmalloc(sizeof(*sgt), GFP_KERNEL);
+ if (!sgt)
+ return -ENOMEM;
+ err = sg_alloc_table(sgt, sglen, GFP_KERNEL);
+ if (err)
+ goto err_sg_alloc;
+
+ for_each_sg(sgt-sgl, sg, sgt-nents, i)
+ sg_set_buf(sg, phys_to_virt(sg_dma_address(src + i)),
+ sg_dma_len(src + i));
+
+ da = (void *)iommu_vmap(isp_iommu, 0, sgt, IOMMU_FLAG);
+ if (IS_ERR(da))
+ goto err_vmap;
+
+ return (dma_addr_t)da;
+
+err_vmap:
+ sg_free_table(sgt);
+err_sg_alloc:
+ kfree(sgt);
+ return -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(ispmmu_vmap);
+
+void ispmmu_vunmap(dma_addr_t da)
+{
+ struct sg_table *sgt;
+
+ sgt = iommu_vunmap(isp_iommu, (u32)da);
+ if (!sgt)
+ return;
+ sg_free_table(sgt);
+ kfree(sgt);
+}
+EXPORT_SYMBOL_GPL(ispmmu_vunmap);
+
+void ispmmu_save_context(void)
+{
+ if (isp_iommu)
+ iommu_save_ctx(isp_iommu);
+}
+
+void ispmmu_restore_context(void)
+{
+ if (isp_iommu)
+ iommu_restore_ctx(isp_iommu);
+}
+
+int __init ispmmu_init(void)
+{
+ int err = 0;
+
+ isp_get();
+ isp_iommu = iommu_get(isp);
+ if (IS_ERR(isp_iommu)) {
+ err = PTR_ERR(isp_iommu);
+ isp_iommu = NULL;
+ }
+ isp_put();
+
+ return err;
+}
+
+void ispmmu_cleanup(void)
+{
+ isp_get();
+ if (isp_iommu)
+ iommu_put(isp_iommu);
+ isp_put();
+ isp_iommu = NULL;
+}
diff --git a/drivers/media/video/isp/ispmmu.h b/drivers/media/video/isp/ispmmu.h
new file mode 100644
index 000..0bc5bcb
--- /dev/null
+++ b/drivers/media/video/isp/ispmmu.h
@@ -0,0 +1,36 @@
+/*
+ * omap iommu wrapper for TI's OMAP3430 Camera ISP
+ *
+ * Copyright (C) 2008--2009 Nokia.
+ *
+ * Contributors:
+ * Hiroshi Doyu hiroshi.d...@nokia.com
+ * Sakari Ailus sakari.ai...@nokia.com
+ *
+ * This package is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+#ifndef OMAP_ISP_MMU_H
+#define OMAP_ISP_MMU_H
+
+#include linux/err.h
+#include linux/scatterlist.h
+
+dma_addr_t ispmmu_vmalloc(size_t bytes);
+void ispmmu_vfree(const dma_addr_t da);
+dma_addr_t ispmmu_kmap(u32 pa, int size);
+void
Re: [PATCH 4/9] omap3isp: Add ISP frontend (CCDC)
On Tue, 2009-03-03 at 12:06 +0200, Sakari Ailus wrote:
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/isp/ispccdc.c | 1568
+
drivers/media/video/isp/ispccdc.h | 203 +
2 files changed, 1771 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/isp/ispccdc.c
create mode 100644 drivers/media/video/isp/ispccdc.h
diff --git a/drivers/media/video/isp/ispccdc.c
b/drivers/media/video/isp/ispccdc.c
new file mode 100644
index 000..80ab762
--- /dev/null
+++ b/drivers/media/video/isp/ispccdc.c
@@ -0,0 +1,1568 @@
+/*
+ * ispccdc.c
+ *
+ * Driver Library for CCDC module in TI's OMAP3 Camera ISP
+ *
+ * Copyright (C) 2009 Texas Instruments, Inc.
+ *
+ * Contributors:
+ * Senthilvadivu Guruswamy svad...@ti.com
+ * Pallavi Kulkarni p-kulka...@ti.com
+ * Sergio Aguirre saagui...@ti.com
+ *
+ * This package is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+#include linux/mutex.h
+#include linux/module.h
+#include linux/uaccess.h
+
+#include isp.h
+#include ispreg.h
+#include ispccdc.h
+#include ispmmu.h
+
+#define LSC_TABLE_INIT_SIZE 50052
+
+static u32 *fpc_table_add;
+static unsigned long fpc_table_add_m;
+
+/**
+ * struct isp_ccdc - Structure for the CCDC module to store its own
information
+ * @ccdc_inuse: Flag to determine if CCDC has been reserved or not (0 or 1).
+ * @ccdcout_w: CCDC output width.
+ * @ccdcout_h: CCDC output height.
+ * @ccdcin_w: CCDC input width.
+ * @ccdcin_h: CCDC input height.
+ * @ccdcin_woffset: CCDC input horizontal offset.
+ * @ccdcin_hoffset: CCDC input vertical offset.
+ * @crop_w: Crop width.
+ * @crop_h: Crop weight.
+ * @ccdc_inpfmt: CCDC input format.
+ * @ccdc_outfmt: CCDC output format.
+ * @vpout_en: Video port output enable.
+ * @wen: Data write enable.
+ * @exwen: External data write enable.
+ * @refmt_en: Reformatter enable.
+ * @ccdcslave: CCDC slave mode enable.
+ * @syncif_ipmod: Image
+ * @obclamp_en: Data input format.
+ * @mutexlock: Mutex used to get access to the CCDC.
+ */
+static struct isp_ccdc {
+ u8 ccdc_inuse;
+ u32 ccdcout_w;
+ u32 ccdcout_h;
+ u32 ccdcin_w;
+ u32 ccdcin_h;
+ u32 ccdcin_woffset;
+ u32 ccdcin_hoffset;
+ u32 crop_w;
+ u32 crop_h;
+ u8 ccdc_inpfmt;
+ u8 ccdc_outfmt;
+ u8 vpout_en;
+ u8 wen;
+ u8 exwen;
+ u8 refmt_en;
+ u8 ccdcslave;
+ u8 syncif_ipmod;
+ u8 obclamp_en;
+ u8 lsc_en;
+ struct mutex mutexlock; /* For checking/modifying ccdc_inuse */
+ u32 wenlog;
+} ispccdc_obj;
+
+static struct ispccdc_lsc_config lsc_config;
+static u8 *lsc_gain_table;
+static unsigned long lsc_ispmmu_addr;
+static int lsc_initialized;
+static u8 ccdc_use_lsc;
+static u8 *lsc_gain_table_tmp;
+
+/* Structure for saving/restoring CCDC module registers*/
+static struct isp_reg ispccdc_reg_list[] = {
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_HD_VD_WID, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_PIX_LINES, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_HORZ_INFO, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_START, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_LINES, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_CULLING, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_HSIZE_OFF, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDR_ADDR, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_CLAMP, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_DCSUB, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_COLPTN, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_BLKCMP, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FPC, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FPC_ADDR, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_ALAW, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_REC656IF, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_CFG, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMTCFG, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_HORZ, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_VERT, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_ADDR0, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_ADDR1, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_ADDR2, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_ADDR3, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_ADDR4, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_ADDR5, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_ADDR6, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_ADDR7, 0},
+ {OMAP3_ISP_IOMEM_CCDC, ISPCCDC_PRGEVEN0, 0},
+
Re: [PATCH 5/9] omap3isp: Add ISP backend (PRV and RSZ)
On Tue, 2009-03-03 at 12:06 +0200, Sakari Ailus wrote:
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/isp/isppreview.c | 1896
++
drivers/media/video/isp/isppreview.h | 350 +++
drivers/media/video/isp/ispresizer.c | 897
drivers/media/video/isp/ispresizer.h | 154 +++
4 files changed, 3297 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/isp/isppreview.c
create mode 100644 drivers/media/video/isp/isppreview.h
create mode 100644 drivers/media/video/isp/ispresizer.c
create mode 100644 drivers/media/video/isp/ispresizer.h
diff --git a/drivers/media/video/isp/isppreview.c
b/drivers/media/video/isp/isppreview.c
new file mode 100644
index 000..242b578
--- /dev/null
+++ b/drivers/media/video/isp/isppreview.c
@@ -0,0 +1,1896 @@
+/*
+ * isppreview.c
+ *
+ * Driver Library for Preview module in TI's OMAP3 Camera ISP
+ *
+ * Copyright (C) 2009 Texas Instruments, Inc.
+ *
+ * Contributors:
+ * Senthilvadivu Guruswamy svad...@ti.com
+ * Pallavi Kulkarni p-kulka...@ti.com
+ * Sergio Aguirre saagui...@ti.com
+ *
+ * This package is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+#include linux/mutex.h
+#include linux/module.h
+#include linux/uaccess.h
+
+#include isp.h
+#include ispreg.h
+#include isppreview.h
+
+static struct ispprev_nf prev_nf_t;
+static struct prev_params *params;
+static int rg_update, gg_update, bg_update, nf_enable, nf_update;
+
+/* Structure for saving/restoring preview module registers */
+static struct isp_reg ispprev_reg_list[] = {
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_HORZ_INFO, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_VERT_INFO, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_RSDR_ADDR, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_RADR_OFFSET, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_DSDR_ADDR, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_DRKF_OFFSET, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_WSDR_ADDR, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_WADD_OFFSET, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_AVE, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_HMED, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_NF, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_WB_DGAIN, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_WBGAIN, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_WBSEL, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_CFA, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_BLKADJOFF, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_RGB_MAT1, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_RGB_MAT2, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_RGB_MAT3, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_RGB_MAT4, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_RGB_MAT5, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_RGB_OFF1, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_RGB_OFF2, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_CSC0, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_CSC1, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_CSC2, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_CSC_OFFSET, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_CNT_BRT, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_CSUP, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_SETUP_YC, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_CDC_THR0, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_CDC_THR1, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_CDC_THR2, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_CDC_THR3, 0x},
+ {OMAP3_ISP_IOMEM_PREV, ISPPRV_PCR, 0x},
+ {0, ISP_TOK_TERM, 0x}
+};
+
+
+/* Default values in Office Flourescent Light for RGBtoRGB Blending */
+static struct ispprev_rgbtorgb flr_rgb2rgb = {
+ { /* RGB-RGB Matrix */
+ {0x01E2, 0x0F30, 0x0FEE},
+ {0x0F9B, 0x01AC, 0x0FB9},
+ {0x0FE0, 0x0EC0, 0x0260}
+ }, /* RGB Offset */
+ {0x, 0x, 0x}
+};
+
+/* Default values in Office Flourescent Light for RGB to YUV Conversion*/
+static struct ispprev_csc flr_prev_csc[] = {
+ {
+ { /* CSC Coef Matrix */
+ {66, 129, 25},
+ {-38, -75, 112},
+ {112, -94 , -18}
+ }, /* CSC Offset */
+ {0x0, 0x0, 0x0}
+ },
+ {
+ { /* CSC Coef Matrix BW */
+ {66, 129, 25},
+ {0, 0, 0},
+ {0, 0, 0}
+ }, /* CSC Offset */
+ {0x0, 0x0, 0x0}
+ },
+ {
+ { /* CSC Coef Matrix
Re: [RFC 0/9] OMAP3 ISP and camera drivers
Sakari Ailus wrote: Any feedback is appreciated. Just one more thing: these patches haven't been checked with checkpatch.pl yet. Style problems are a certainty. I'm working on the issue. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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] WinTV HVR-1800 analog Satus
Matt Garretson wrote: Steven Toth wrote: Dustin Coates wrote: Any update on the status of analouge for this card? I really would Last I checked it worked fine for me. Does anyone have an HVR-1800 (digital or analog) coexisting with a PVR-250? Mythtv-setup crashes for me when scanning ATSC/QAM channels on the HVR-1800. Admittedly, I haven't tried to debug it beyond that. But I'm just wondering if these IVTV and DVB devices can coexist at all. Also, does the 2.6.27 kernel have recent enough v4l/dvb stuff for the HVR-1800 merged in, or should I still be pulling from the linuxtv repository? Thanks... -Matt ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb QAM-Cable scans fine with my mythtv-21-fixes, co-existing with my Twinhan 1020 DVB-S...just my analogue support not working...ubuntu 8.10 64-bit stock kernel JJ -- 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] pxa_camera: Redesign DMA handling
(moved to the new v4l list)
Nice! A couple of questions / remarks though.
On Mon, 2 Mar 2009, Robert Jarzmik wrote:
The DMA transfers in pxa_camera showed some weaknesses in
multiple queued buffers context :
- poll/select problem
The order between list pcdev-capture and DMA chain was
not the same. This creates a discrepancy between video
buffers marked as done by the IRQ handler, and the
really finished video buffer.
Could you please describe where and how the order could get wrong?
- multiple buffers DMA starting
When multiple buffers were queued, the DMA channels were
You mean multiple scatter-gather elements?
always started right away. This is not optimal, as a
special case appears when the first EOM was not yet
reached, and the DMA channels were prematurely started.
What is EOM? I see End of Line, End of Frame, End of Active Video, End of
Transfer. I only see End of Message on the PXA MSL interface, which
doesn't seem to be related. TBH, I do not quite understand what you mean
here. What do we have to wait for before starting DMA channels?
Ok, after working through the whole patch, I think, you meant starting DMA
in the middle of a frame and thus getting an incomplete frame, which you
changed using the capture (not DMA) End of Frame interrupt, right?
- YUV planar formats hole
All planes were PAGE aligned (ie. 4096 bytes
aligned). This is not consistent with YUV422 format,
which requires Y, U and V planes glued together.
The new implementation forces the alignement on 8 bytes
(DMA requirement), which is almost always the case
(granted by width x height being a multiple of 8).
Then we shall adjust frame sizes to produce a multiple of 8.
- Maintainability
DMA code was a bit ofsuscated. Rationalize the code to be
s/ofsuscated/obfuscated/:-)
easily maintainable by anyone.
Nice. Well, you'd really do me a favour, if you could split it at least
into two patches: maintainability improvements (split out functions,
whatever else), and then fixes. Splitting off planar alignment fix should
also be pretty straightforward, especially worth splitting off, when you
add size rounding up. Mike suggested another split, you may decide which
one you hold for more meaningful, or maybe both.
This patch attemps to address these issues.
The test cases include tests in both YUV422 and RGB565 :
- a picture of size 111 x 111 (cross RAM pages example)
- a picture of size 1023 x 4 in (under 1 RAM page)
- a picture of size 1024 x 4 in (exactly 1 RAM page)
- a picture of size 1025 x 4 in (over 1 RAM page)
- a picture of size 1280 x 1024 (many RAM pages)
What exactly was the problem before your patch? How do I reproduce it? I
guess, it should also be visible with monochrome or Bayer formats.
Signed-off-by: Robert Jarzmik robert.jarz...@free.fr
---
drivers/media/video/pxa_camera.c | 400
+++---
1 files changed, 243 insertions(+), 157 deletions(-)
diff --git a/drivers/media/video/pxa_camera.c
b/drivers/media/video/pxa_camera.c
index e3e6b29..ccedfaf 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -243,12 +243,12 @@ static int pxa_videobuf_setup(struct videobuf_queue
*vq, unsigned int *count,
/* planar capture requires Y, U and V buffers to be page aligned */
if (pcdev-channels == 3) {
- *size = PAGE_ALIGN(icd-width * icd-height); /* Y pages */
- *size += PAGE_ALIGN(icd-width * icd-height / 2); /* U pages */
- *size += PAGE_ALIGN(icd-width * icd-height / 2); /* V pages */
+ *size = roundup(icd-width * icd-height, 8); /* Y pages */
+ *size += roundup(icd-width * icd-height / 2, 8); /* U pages */
+ *size += roundup(icd-width * icd-height / 2, 8); /* V pages */
Every time I see code like
x = u;
x += v;
x += w;
...
or
x = u;
x |= v;
...
makes me wonder why not just write
x = u + /* need u */
v + /* and v */
w; /* and w */
This way you explicitly tell the compiler you don't need intermediate
values and it can perform any optimisations it likes. I actually looked at
assembly code - the compiler does save intermediate values each time in
*size - as in case above, which involves a pointer dereference... I think,
would be cleaner to chain additions as suggested above.
} else {
- *size = icd-width * icd-height *
- ((icd-current_fmt-depth + 7) 3);
+ *size = roundup(icd-width * icd-height *
+ ((icd-current_fmt-depth + 7) 3), 8);
}
if (0 == *count)
@@ -289,19 +289,58 @@ static void free_buffer(struct videobuf_queue *vq,
struct pxa_buffer *buf)
buf-vb.state = VIDEOBUF_NEEDS_INIT;
}
+static int
Re: Support for SkyStar USB 2 ?
Hi Ronny, On Tue, 3 Mar 2009, ronny.ban...@nexgo.de wrote: the current flexcop-usb driver supports only USB 1.1 devices. Is there any plan to support USB 2.0 devices ? The device id is 13d0:2282. For testing I have simply changed the flexcop_usb_table structur to this ids. But of course is does not work. The hardware components are the same of the SkyStar2 PCI (CX24113 tuner...). Are you sure about that? Can you please send hires-pictures of the innards of the USB box? Patrick. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Aw: Re: Support for SkyStar USB 2 ?
Hi Patrick, Im pretty sure thats the same components. The following microchips are on the board: 1x Technisat Flexcop IIB MMRY3-000 0628 1x PLX NET2282-AB35PC (PCI-USB Bridge) 1x ISL6421 and some other very small chips. In the tuner bracket: 1x 24113A-12Z 1x CX24123-11Z I will send the pictures tomorrow from my work office, because I have only Light-DSL at home. Best Regards Ronny. - Original Nachricht Von: Patrick Boettcher patrick.boettc...@desy.de An: ronny.ban...@nexgo.de Datum: 03.03.2009 18:18 Betreff: Re: Support for SkyStar USB 2 ? Hi Ronny, On Tue, 3 Mar 2009, ronny.ban...@nexgo.de wrote: the current flexcop-usb driver supports only USB 1.1 devices. Is there any plan to support USB 2.0 devices ? The device id is 13d0:2282. For testing I have simply changed the flexcop_usb_table structur to this ids. But of course is does not work. The hardware components are the same of the SkyStar2 PCI (CX24113 tuner...). Are you sure about that? Can you please send hires-pictures of the innards of the USB box? Patrick. -- 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 Erwischt! Bei Arcor sehen Sie die besten Promi-Bilder riesengroß und in Top-Qualität. Hier finden Sie die schönsten Schnappschüsse auf dem roten Teppich, lernen die Frauen des Womanizers Boris Becker kennen und schauen den Royals ins Wohnzimmer. Viel Spaß auf Ihrer virtuellen Reise durch die Welt der Stars und Sternchen: http://vip.arcor.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] pxa_camera: Redesign DMA handling
Guennadi Liakhovetski g.liakhovet...@gmx.de writes:
(moved to the new v4l list)
Wow, I missed a couple of mail I see ... :) I really should subscribe to that
one ...
On Mon, 2 Mar 2009, Robert Jarzmik wrote:
The DMA transfers in pxa_camera showed some weaknesses in
multiple queued buffers context :
- poll/select problem
The order between list pcdev-capture and DMA chain was
not the same. This creates a discrepancy between video
buffers marked as done by the IRQ handler, and the
really finished video buffer.
Could you please describe where and how the order could get wrong?
- multiple buffers DMA starting
When multiple buffers were queued, the DMA channels were
You mean multiple scatter-gather elements?
always started right away. This is not optimal, as a
special case appears when the first EOM was not yet
reached, and the DMA channels were prematurely started.
What is EOM? I see End of Line, End of Frame, End of Active Video, End of
Transfer. I only see End of Message on the PXA MSL interface, which
doesn't seem to be related. TBH, I do not quite understand what you mean
here. What do we have to wait for before starting DMA channels?
Ok, after working through the whole patch, I think, you meant starting DMA
in the middle of a frame and thus getting an incomplete frame, which you
changed using the capture (not DMA) End of Frame interrupt, right?
Right. And EOM should have been EOF (End of Frame as you guessed).
- YUV planar formats hole
All planes were PAGE aligned (ie. 4096 bytes
aligned). This is not consistent with YUV422 format,
which requires Y, U and V planes glued together.
The new implementation forces the alignement on 8 bytes
(DMA requirement), which is almost always the case
(granted by width x height being a multiple of 8).
Then we shall adjust frame sizes to produce a multiple of 8.
Well, not necessarily, at the moment you can use a size of 111x111 and it is
working (even if that kind of size is a bit crazy :))
This point is at your choice. If you tell me you want to force it to multiples
of 8, I'll go for it. It will _really_ simplify the whole roundup() gymnastic.
- Maintainability
DMA code was a bit ofsuscated. Rationalize the code to be
s/ofsuscated/obfuscated/:-)
Yes.
easily maintainable by anyone.
Nice. Well, you'd really do me a favour, if you could split it at least
into two patches: maintainability improvements (split out functions,
whatever else), and then fixes. Splitting off planar alignment fix should
also be pretty straightforward, especially worth splitting off, when you
add size rounding up. Mike suggested another split, you may decide which
one you hold for more meaningful, or maybe both.
Maintainability and fixes are intermixed, as the whole DMA usage was
rewritten. It's not that easy. Splitting off planar alignment is easy, but fixes
come from the new architecture after the rewrite.
Even if I try, I don't think I'll succeed. One example for demonstration :
- in the former pxa_videobuf_queue(), when a buffer was queued while another
was already active, a dummy descriptor was added, and then the new buffer was
chained with the actively running buffer. See code below :
- } else {
- buf_dma-sg_cpu[nents].ddadr =
- DDADR(pcdev-dma_chans[i]);
- }
-
- /* The next descriptor is the dummy descriptor */
- DDADR(pcdev-dma_chans[i]) = buf_dma-sg_dma + nents *
- sizeof(struct pxa_dma_desc);
The fix is in the code refactoring, as now the buffer is always added at the
tail of the queue through pxa_dma_add_tail_buf().
This patch attemps to address these issues.
The test cases include tests in both YUV422 and RGB565 :
- a picture of size 111 x 111 (cross RAM pages example)
- a picture of size 1023 x 4 in (under 1 RAM page)
- a picture of size 1024 x 4 in (exactly 1 RAM page)
- a picture of size 1025 x 4 in (over 1 RAM page)
- a picture of size 1280 x 1024 (many RAM pages)
What exactly was the problem before your patch? How do I reproduce it? I
guess, it should also be visible with monochrome or Bayer formats.
The problem can be reproduced with the capture_example.c taken from v4l2 test
utilities. I can reproduce it from time to time if I force my cpufreq to the
lowest value (powersave), and queue 4 buffers of a size 1280x1024.
Sometimes, the process just stalls on a select timeout.
makes me wonder why not just write
x = u + /* need u */
v + /* and v */
w; /* and w */
Ah, didn't wan't to break authorship ... Will amend.
+static int calculate_dma_sglen(struct scatterlist *sg, int sg_first,
+ int sg_first_ofs, int size)
+{
+int sg_i, offset;
+int dma_len, xfer_len;
[cron job] ERRORS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below.) Results of the daily build of v4l-dvb: date:Tue Mar 3 19:00:03 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10785:91f9c6c451f7 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.16.61-armv5: OK linux-2.6.17.14-armv5: OK linux-2.6.18.8-armv5: OK linux-2.6.19.5-armv5: OK linux-2.6.20.21-armv5: OK linux-2.6.21.7-armv5: OK linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-rc5-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc5-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc5-armv5-omap2: OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-rc5-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc5-m32r: OK linux-2.6.16.61-mips: ERRORS linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc5-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29-rc5-powerpc64: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: OK linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29-rc5-x86_64: WARNINGS fw/apps: WARNINGS spec: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc5): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.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: [PULL][Stable]Please pull http://linuxtv.org/hg/~eandren/v4l-dvb
On Mon, 02 Mar 2009 20:44:39 +0100 Erik Andrén erik.and...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The pull http://linuxtv.org/hg/~eandren/v4l-dvb is based on the gscpa stable (v4l-dvb) repository and contains one important fix that needs to go into 2.6.29. Please pull ASAP. Hi Eric and Jean-françois, I've just pulled from this tree. 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
[PATCH] to gspca, to support SQ905C cameras.
The SQ905C cameras (0x2770:0x905C) cameras, as well as two other closely related varieties (0x2770:0x9050 and 0x2770:0x913D) are supported in what follows. These cameras are the successors in the marketplace of the SQ905 cameras. They are similar to the SQ905 cameras, in that they use bulk transport while streaming, and thus the driver functions similarly, using a workqueue to perform the streaming. However, there are also some serious differences. These differences include -- a different structure of the commands -- commands do not pass a data byte to the camera -- commands do not require a subsequent read operation -- while streaming, there are no commands sent during a frame download, nor is there an ack between frames. Thus, the only command sent during streaming is a command to quit streaming. -- frame header is of a different size -- the SQ905C cameras all stream compressed data, whereas the data for the older SQ905 cameras is not compressed -- since compressed frames are of variable size, the frame header is read first and contains the data size for the coming frame -- the supported resolution settings are different I should also mention that the introduction of support for these cameras requires an additional fourcc code to be introduced in linux/include/linux/videodev2.h, and the addition of the decompression algorithm in libv4lconvert. I have submitted the libv4lconvert patch a couple of days ago. The code in the new sq905c.c is based upon the structure of the code in gspca/sq905.c, and upon the code in libgphoto2/camlibs/digigr8, which supports the same set of cameras in stillcam mode. I am a co-author of gspca/sq905.c and I am the sole author of libgphoto2/camlibs/digigr8, which is licensed under the LGPL. I hereby give myself permission to use my own code from libgphoto2 in gspca/sq905c.c. Signed-off-by Theodore Kilgore kilg...@auburn.edu contents of the file sq905c.patch follow - diff -uprN linuxa/drivers/media/video/gspca/Kconfig linuxb/drivers/media/video/gspca/Kconfig --- linuxa/drivers/media/video/gspca/Kconfig2009-02-23 23:59:07.0 -0600 +++ linuxb/drivers/media/video/gspca/Kconfig2009-02-28 19:55:49.0 -0600 @@ -185,6 +185,15 @@ config USB_GSPCA_SQ905 To compile this driver as a module, choose M here: the module will be called gspca_sq905. +config USB_GSPCA_SQ905C + tristate SQ Technologies SQ905C based USB Camera Driver + depends on VIDEO_V4L2 USB_GSPCA + help + Say Y here if you want support for cameras based on the SQ905C chip. + + To compile this driver as a module, choose M here: the + module will be called gspca_sq905c. + config USB_GSPCA_STK014 tristate Syntek DV4000 (STK014) USB Camera Driver depends on VIDEO_V4L2 USB_GSPCA diff -uprN linuxa/drivers/media/video/gspca/Makefile linuxb/drivers/media/video/gspca/Makefile --- linuxa/drivers/media/video/gspca/Makefile 2009-02-23 23:59:07.0 -0600 +++ linuxb/drivers/media/video/gspca/Makefile 2009-02-28 19:54:54.0 -0600 @@ -17,6 +17,7 @@ obj-$(CONFIG_USB_GSPCA_SPCA506) += gspc obj-$(CONFIG_USB_GSPCA_SPCA508) += gspca_spca508.o obj-$(CONFIG_USB_GSPCA_SPCA561) += gspca_spca561.o obj-$(CONFIG_USB_GSPCA_SQ905)+= gspca_sq905.o +obj-$(CONFIG_USB_GSPCA_SQ905C)+= gspca_sq905c.o obj-$(CONFIG_USB_GSPCA_SUNPLUS) += gspca_sunplus.o obj-$(CONFIG_USB_GSPCA_STK014) += gspca_stk014.o obj-$(CONFIG_USB_GSPCA_T613) += gspca_t613.o @@ -43,6 +44,7 @@ gspca_spca506-objs := spca506.o gspca_spca508-objs := spca508.o gspca_spca561-objs := spca561.o gspca_sq905-objs:= sq905.o +gspca_sq905c-objs:= sq905c.o gspca_stk014-objs := stk014.o gspca_sunplus-objs := sunplus.o gspca_t613-objs := t613.o diff -uprN linuxa/drivers/media/video/gspca/sq905c.c linuxb/drivers/media/video/gspca/sq905c.c --- linuxa/drivers/media/video/gspca/sq905c.c 1969-12-31 18:00:00.0 -0600 +++ linuxb/drivers/media/video/gspca/sq905c.c 2009-03-02 20:42:42.0 -0600 @@ -0,0 +1,330 @@ +/* + * SQ905C subdriver + * + * Copyright (C) 2009 Theodore Kilgore + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * any later version. + * + * 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 330, Boston, MA 02111-1307 USA + */ + +/* + * + * This driver uses work done in + *
[PULL] http://udev.netup.ru/hg/v4l-dvb-netup
Mauro, After cleanups and fixes. Please pull from http://udev.netup.ru/hg/v4l-dvb-netup for the following 10 changesets: 01/10: Add init code for NetUP Dual DVB-S2 CI card http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=a671cee39c95 02/10: Add EEPROM code for NetUP Dual DVB-S2 CI card. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=9aebc98deef7 03/10: Add CIMax(R) SP2 Common Interface code for NetUP Dual DVB-S2 CI card http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=009a5c8af780 04/10: Add support for ST STV6110 silicon tuner. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=ea3c0d6fa7d3 05/10: Add support for ST LNBH24 LNB power controller. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=ba740eb2348e 06/10: Add headers for ST STV0900 dual demodulator. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=b3f0151f8b6d 07/10: Add more headers for ST STV0900 dual demodulator. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=208740992e6c 08/10: Add core code for ST STV0900 dual demodulator. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=69bf69e14207 09/10: Add support for ST STV0900 dual demodulator. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=74dfadeb1162 10/10: Add support for NetUP Dual DVB-S2 CI card http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=e8ebbf5835b8 b/linux/drivers/media/dvb/frontends/lnbh24.h | 55 b/linux/drivers/media/dvb/frontends/stv0900.h | 62 b/linux/drivers/media/dvb/frontends/stv0900_core.c | 1961 ++ b/linux/drivers/media/dvb/frontends/stv0900_init.h | 439 ++ b/linux/drivers/media/dvb/frontends/stv0900_priv.h | 430 ++ b/linux/drivers/media/dvb/frontends/stv0900_reg.h | 3787 + b/linux/drivers/media/dvb/frontends/stv0900_sw.c | 2847 +++ b/linux/drivers/media/dvb/frontends/stv6110.c | 457 ++ b/linux/drivers/media/dvb/frontends/stv6110.h | 62 b/linux/drivers/media/video/cx23885/cimax2.c | 484 ++ b/linux/drivers/media/video/cx23885/cimax2.h | 47 b/linux/drivers/media/video/cx23885/netup-eeprom.c | 117 b/linux/drivers/media/video/cx23885/netup-eeprom.h | 42 b/linux/drivers/media/video/cx23885/netup-init.c | 125 b/linux/drivers/media/video/cx23885/netup-init.h | 25 linux/Documentation/video4linux/CARDLIST.cx23885 | 1 linux/drivers/media/dvb/frontends/Kconfig | 18 linux/drivers/media/dvb/frontends/Makefile | 3 linux/drivers/media/dvb/frontends/lnbp21.c | 41 linux/drivers/media/dvb/frontends/lnbp21.h | 50 linux/drivers/media/video/cx23885/Kconfig | 1 linux/drivers/media/video/cx23885/Makefile | 4 linux/drivers/media/video/cx23885/cx23885-cards.c | 53 linux/drivers/media/video/cx23885/cx23885-core.c | 20 linux/drivers/media/video/cx23885/cx23885-dvb.c | 106 linux/drivers/media/video/cx23885/cx23885-reg.h | 2 linux/drivers/media/video/cx23885/cx23885.h | 3 27 files changed, 11215 insertions(+), 27 deletions(-) Thanks, Igor -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge NOVA-T 500 falls over after warm reboot
Hi, Same here. I've been observing the same behaviour in the lastest times. I can't say exactly since when this happens, though. I've observed that stopping mythbackend, unloading the driver with 'rmmod dvb_usb_dib0700' and rebooting again seems to fix the problem. By the dmesg it seems like, on a warm reboot, it fails to detect the card as 'warm' state (dmesg says it's 'cold'), so it attempts to load the firmware again, which fails and leaves the card in an unusable state. Best regards, Eduard 2009/3/3 uTaR utar...@gmail.com: Just thought I would report some unusual behaviour I am seeing on my Nova-T 500. Basically the card works fine with a cold boot but falls over rapidly after a warm reboot. This started after I compiled the latest v4l source tree (as at 22 Feb 09) due to me adding a Tevii S650 to my system. At first I thought it was the Tevii which was causing the problem but testing showed the Nova falls over irrespective of if the Tevii is attached. I'm running Ubuntu with 2.6.27-11 and I never had this issue with v4l running out of the box. Sample of the log after the Nova falls over follows: [ 117.920002] ehci_hcd :05:00.2: force halt; handhake f88f4c14 4000 - -110 [ 129.412342] mt2060 I2C write failed [ 132.412253] mt2060 I2C write failed [ 133.713596] mt2060 I2C write failed [ 136.712264] mt2060 I2C write failed [ 138.004603] mt2060 I2C write failed [ 141.004564] mt2060 I2C write failed [ 147.177361] mt2060 I2C write failed [ 150.176124] mt2060 I2C write failed [ 171.026988] mt2060 I2C write failed [ 171.041701] mt2060 I2C write failed (len=2) [ 171.041824] mt2060 I2C write failed (len=6) [ 171.041922] mt2060 I2C read failed -- 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
[PATCH 2/5] DW9710: Add driver
This driver has been currently being tested with
OMAP3430SDP platform, working on top of MT9P012
sensor.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/Kconfig |8 +
drivers/media/video/Makefile |1 +
drivers/media/video/dw9710.c | 548 +
drivers/media/video/dw9710_priv.h | 57
include/media/dw9710.h| 35 +++
5 files changed, 649 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/dw9710.c
create mode 100644 drivers/media/video/dw9710_priv.h
create mode 100644 include/media/dw9710.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 05e9fa1..225d9cf 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -313,6 +313,14 @@ config VIDEO_MT9P012
MT9P012 camera. It is currently working with the TI OMAP3
camera controller.
+config VIDEO_DW9710
+ tristate Lens driver for DW9710
+ depends on I2C VIDEO_V4L2
+ ---help---
+ This is a Video4Linux2 lens driver for the Dongwoon
+ DW9710 coil. It is currently working with the TI OMAP3
+ camera controller and micron MT9P012 sensor.
+
config VIDEO_SAA7110
tristate Philips SAA7110 video decoder
depends on VIDEO_V4L1 I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index c445099..52a34d9 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -112,6 +112,7 @@ obj-$(CONFIG_VIDEO_OMAP3) += omap34xxcam.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_MT9P012) += mt9p012.o
+obj-$(CONFIG_VIDEO_DW9710) += dw9710.o
obj-$(CONFIG_USB_DABUSB)+= dabusb.o
obj-$(CONFIG_USB_OV511) += ov511.o
diff --git a/drivers/media/video/dw9710.c b/drivers/media/video/dw9710.c
new file mode 100644
index 000..362cb0d
--- /dev/null
+++ b/drivers/media/video/dw9710.c
@@ -0,0 +1,548 @@
+/*
+ * drivers/media/video/dw9710.c
+ *
+ * DW9710 Coil Motor (LENS) driver
+ *
+ * Copyright (C) 2008 Texas Instruments.
+ *
+ * Contributors:
+ * Troy Laramy t-lar...@ti.com
+ * Mohit Jalori mjal...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ *
+ */
+
+#include linux/mutex.h
+#include linux/i2c.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/cdev.h
+#include linux/device.h
+
+#include mach/gpio.h
+
+#include media/v4l2-int-device.h
+#include media/dw9710.h
+
+#include dw9710_priv.h
+
+static struct dw9710_device dw9710 = {
+ .state = DW9710_LENS_NOT_DETECTED,
+ .current_lens_posn = DW9710_DEF_LENS_POSN,
+};
+
+static struct vcontrol {
+ struct v4l2_queryctrl qc;
+ int current_value;
+} video_control[] = {
+ {
+ {
+ .id = V4L2_CID_FOCUS_ABSOLUTE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Focus, Absolute,
+ .minimum = 0,
+ .maximum = DW9710_MAX_FOCUS_POS,
+ .step = DW9710_LENS_POSN_STEP,
+ .default_value = DW9710_DEF_LENS_POSN,
+ },
+ .current_value = DW9710_DEF_LENS_POSN,
+ }
+};
+
+/**
+ * find_vctrl - Finds the requested ID in the video control structure array
+ * @id: ID of control to search the video control array for
+ *
+ * Returns the index of the requested ID from the control structure array
+ */
+static int find_vctrl(int id)
+{
+ int i;
+
+ if (id V4L2_CID_BASE)
+ return -EDOM;
+
+ for (i = (ARRAY_SIZE(video_control) - 1); i = 0; i--) {
+ if (video_control[i].qc.id == id)
+ return i;
+ }
+
+ return -EINVAL;
+}
+
+/**
+ * dw9710_reg_read - Reads a value from a register in DW9710 Coil driver
device.
+ * @client: Pointer to structure of I2C client.
+ * @value: Pointer to u16 for returning value of register to read.
+ *
+ * Returns zero if successful, or non-zero otherwise.
+ **/
+static int dw9710_reg_read(struct i2c_client *client, u16 *value)
+{
+ int err;
+ struct i2c_msg msg[1];
+ unsigned char data[2];
+
+ if (!client-adapter)
+ return -ENODEV;
+
+ msg-addr = client-addr;
+ msg-flags = I2C_M_RD;
+ msg-len = 2;
+ msg-buf = data;
+
+ data[0] = 0;
+ data[1] = 0;
+
+ err = i2c_transfer(client-adapter, msg, 1);
+
+ if (err = 0) {
+ err = ((data[0] 0xFF) 8) | (data[1]);
+ *value = err;
+ return 0;
+ }
+ return err;
+}
+
+/**
+ * dw9710_reg_write - Writes a value to a register in DW9710 Coil driver
device.
+ * @client: Pointer to structure of I2C client.
+ * @value: Value of register to write.
+ *
+ * Returns zero if
RE: [RFC 0/5] Sensor drivers for OMAP3430SDP and LDP camera
Adding links for easier reference to required patches: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto Sent: Tuesday, March 03, 2009 2:44 PM To: linux-media@vger.kernel.org; linux-o...@vger.kernel.org Cc: Sakari Ailus; Tuukka.O Toivonen; Hiroshi DOYU; DongSoo(Nathaniel) Kim; MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth Subject: [RFC 0/5] Sensor drivers for OMAP3430SDP and LDP camera This patch series depends on the following patches: - Add TWL4030 registers, posted by Tuukka Toivonen on March 2nd. http://marc.info/?l=linux-omapm=123597520231668w=2 - OMAP3 ISP and camera drivers patch series, posted by Sakari Ailus on March 3rd. (Please follow his instructions to pull from gitorious.org server) http://marc.info/?l=linux-omapm=123607483202215w=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: General protection fault on rmmod cx8800
On Tue, 3 Mar 2009 12:14:06 -0800 (PST), Trent Piepho wrote: On Tue, 3 Mar 2009, Jean Delvare wrote: On Tue, 3 Mar 2009 01:40:00 -0800 (PST), Trent Piepho wrote: On Mon, 2 Mar 2009, Jean Delvare wrote: In 2.6.20 delayed_work was split from work_struct. The concept of delayed work was already there and schedule_delayed_work() hasn't changed. I think this can also be handled with a compat.h change that defines delayed_work to work_struct. That will only be a problem on pre 2.6.20 kernels if some code decides to define identifiers named work_struct and delayed_work in the same scope. There are currently no identifier named delayed_work in any driver and one driver (sq905) has a structure member named work_struct. So I think it'll be ok. Wow, I didn't expect that many different compatibility issues. This goes beyond the time I am ready to spend on it, I'm afraid. I already have a patch for compat.h that handles the last remaining issue. You don't have to do anything. Ah, very nice then. Please push it to the v4l-dvb repository so that I can send my own patch. I will also fix the 3 other drivers that have the same bug (ir-kbd-i2c, saa6588 and em28xx-input). -- Jean Delvare -- 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
[PULL] http://linuxtv.org/hg/~tap/v4l-dvb
Mauro, Please pull from http://linuxtv.org/hg/~tap/v4l-dvb for the following 4 changesets: 01/04: videodev: not possible to register NULL video_device http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=3c87763acae5 02/04: cx88: remove unnecessary forward declaration of cx88_core http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=ffc649bf14a6 03/04: compat: rename struct delayed_work to work_struct on pre-2.6.20 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=62d29b435438 04/04: v4l2: Move code to zero querybuf output struct to v4l2_ioctl http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=d31e6e7a8241 linux/drivers/media/dvb/b2c2/flexcop-pci.c|4 linux/drivers/media/dvb/dvb-usb/dvb-usb.h |4 linux/drivers/media/radio/radio-si470x.c |4 linux/drivers/media/video/cx88/cx88.h |1 - linux/drivers/media/video/em28xx/em28xx.h |4 linux/drivers/media/video/meye.c |4 linux/drivers/media/video/stk-webcam.c|8 +--- linux/drivers/media/video/usbvision/usbvision-video.c |3 --- linux/drivers/media/video/v4l2-dev.c |7 +++ linux/drivers/media/video/v4l2-ioctl.c|5 + linux/drivers/media/video/zoran/zoran_driver.c|6 -- v4l/compat.h |8 12 files changed, 17 insertions(+), 41 deletions(-) Thanks, Trent -- 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/5] Sensor drivers for OMAP3430SDP and LDP camera
On Tuesday 03 March 2009 21:44:12 Aguirre Rodriguez, Sergio Alberto wrote: This patch series depends on the following patches: - Add TWL4030 registers, posted by Tuukka Toivonen on March 2nd. - OMAP3 ISP and camera drivers patch series, posted by Sakari Ailus on March 3rd. (Please follow his instructions to pull from gitorious.org server) Sergio, Sakari, I'm feeling quite uncomfortable about this series with regards to the use of the v4l2-int API instead of v4l2_subdev. I know that it is on the TODO list, but every driver that is merged that uses v4l2-int will later mean extra work. I and others have been working very hard to get the existing ioctl-based i2c modules converted in time for the 2.6.30 merge window. It looks like I'll be able to have it done in time (fingers crossed :-) ). So it is rather sad to see new modules that do not yet use it. Right now the v4l2_device and v4l2_subdev framework is pretty basic and so the amount of work to do the conversion is still limited, but once I've finished my initial conversion I'll be adding lots more features, do cleanups, and generally improve the framework substantially. Any existing modules that use v4l2_device and v4l2_subdev will be updated by me. But I'm not going to do that for modules using v4l2-int, that will be the responsibility of the module's author when he converts it to v4l2_subdev. So the longer you wait, the more work that will be. I *strongly* recommend that the conversion to the new framework is done first. I know it might delay inclusion of some drivers, but my expectation based on all the other conversions I've done until now is that it will actually simplify the drivers. My experiences with it have been uniformly positive and it should be possible to use it as well with the ISP module or other logical sub-devices. There are lots of interesting possibilities there that you do not have with v4l2-int. Best regards, Hans This has been tested with: - SDP3430-VG5.0.1 with OMAP3430-ES3.1 daughter board upgrade. - Camkit V3.0.1 with MT9P012 and OV3640 sensors - LDP with OV3640 sensor Sergio Aguirre (5): MT9P012: Add driver DW9710: Add driver OV3640: Add driver OMAP3430SDP: Add support for Camera Kit v3 LDP: Add support for built-in camera arch/arm/mach-omap2/Makefile|6 +- arch/arm/mach-omap2/board-3430sdp-camera.c | 490 + arch/arm/mach-omap2/board-3430sdp.c | 42 +- arch/arm/mach-omap2/board-ldp-camera.c | 203 +++ arch/arm/mach-omap2/board-ldp.c | 17 + arch/arm/plat-omap/include/mach/board-3430sdp.h |1 + arch/arm/plat-omap/include/mach/board-ldp.h |1 + drivers/media/video/Kconfig | 31 + drivers/media/video/Makefile|3 + drivers/media/video/dw9710.c| 548 ++ drivers/media/video/dw9710_priv.h | 57 + drivers/media/video/mt9p012.c | 1890 +++ drivers/media/video/mt9p012_regs.h | 74 + drivers/media/video/ov3640.c| 2202 +++ drivers/media/video/ov3640_regs.h | 600 ++ include/media/dw9710.h | 35 + include/media/mt9p012.h | 37 + include/media/ov3640.h | 31 + 18 files changed, 6265 insertions(+), 3 deletions(-) create mode 100644 arch/arm/mach-omap2/board-3430sdp-camera.c create mode 100644 arch/arm/mach-omap2/board-ldp-camera.c create mode 100644 drivers/media/video/dw9710.c create mode 100644 drivers/media/video/dw9710_priv.h create mode 100644 drivers/media/video/mt9p012.c create mode 100644 drivers/media/video/mt9p012_regs.h create mode 100644 drivers/media/video/ov3640.c create mode 100644 drivers/media/video/ov3640_regs.h create mode 100644 include/media/dw9710.h create mode 100644 include/media/mt9p012.h create mode 100644 include/media/ov3640.h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Support alternate resolutions for sq905
Add support for the alternate resolutions offered by SQ-905 based cameras. As
well as 320x240 all cameras can do 160x120 and some can do 640x480.
Signed-off-by: Adam Baker li...@baker-net.org.uk
---
The patch to detect orientation needs to follow this as that is also simplified
by
the modified identity check that this introduces.
---
diff -r 332a4d374f56 linux/drivers/media/video/gspca/sq905.c
--- a/linux/drivers/media/video/gspca/sq905.c Sat Feb 28 11:49:32 2009 +0100
+++ b/linux/drivers/media/video/gspca/sq905.c Tue Mar 03 21:20:02 2009 +
@@ -60,23 +60,29 @@ MODULE_LICENSE(GPL);
#define SQ905_PING 0x07/* when reading an idling command */
#define SQ905_READ_DONE 0xc0/* ack bulk read completed */
+/* Any non-zero value in the bottom 2 bits of the 2nd byte of
+ * the ID appears to indicate the camera can do 640*480. If the
+ * LSB of that byte is set the image is just upside down, otherwise
+ * it is rotated 180 degrees. */
+#define SQ905_HIRES_MASK 0x0300
+#define SQ905_ORIENTATION_MASK 0x0100
+
/* Some command codes. These go in the index slot. */
#define SQ905_ID 0xf0 /* asks for model string */
#define SQ905_CONFIG 0x20 /* gets photo alloc. table, not used here */
#define SQ905_DATA0x30 /* accesses photo data, not used here */
#define SQ905_CLEAR 0xa0 /* clear everything */
-#define SQ905_CAPTURE_LOW 0x60 /* Starts capture at 160x120 */
-#define SQ905_CAPTURE_MED 0x61 /* Starts capture at 320x240 */
+#define SQ905_CAPTURE_LOW 0x60/* Starts capture at 160x120 */
+#define SQ905_CAPTURE_MED 0x61/* Starts capture at 320x240 */
+#define SQ905_CAPTURE_HIGH 0x62/* Starts capture at 640x480 (some cams
only) */
/* note that the capture command also controls the output dimensions */
-/* 0x60 - 160x120, 0x61 - 320x240 0x62 - 640x480 depends on camera */
-/* 0x62 is not correct, at least for some cams. Should be 0x63 ? */
/* Structure to hold all of our device specific stuff */
struct sd {
struct gspca_dev gspca_dev; /* !! must be the first item */
- u8 cam_type;
+ const struct v4l2_pix_format *cap_mode;
/*
* Driver stuff
@@ -85,31 +91,22 @@ struct sd {
struct workqueue_struct *work_thread;
};
-/* The driver only supports 320x240 so far. */
-static struct v4l2_pix_format sq905_mode[1] = {
+static struct v4l2_pix_format sq905_mode[] = {
+ { 160, 120, V4L2_PIX_FMT_SBGGR8, V4L2_FIELD_NONE,
+ .bytesperline = 160,
+ .sizeimage = 160 * 120,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .priv = 0},
{ 320, 240, V4L2_PIX_FMT_SBGGR8, V4L2_FIELD_NONE,
.bytesperline = 320,
.sizeimage = 320 * 240,
.colorspace = V4L2_COLORSPACE_SRGB,
+ .priv = 0},
+ { 640, 480, V4L2_PIX_FMT_SBGGR8, V4L2_FIELD_NONE,
+ .bytesperline = 640,
+ .sizeimage = 640 * 480,
+ .colorspace = V4L2_COLORSPACE_SRGB,
.priv = 0}
-};
-
-struct cam_type {
- u32 ident_word;
- char *name;
- struct v4l2_pix_format *min_mode;
- u8 num_modes;
- u8 sensor_flags;
-};
-
-#define SQ905_FLIP_HORIZ (1 0)
-#define SQ905_FLIP_VERT (1 1)
-
-/* Last entry is default if nothing else matches */
-static struct cam_type cam_types[] = {
- { 0x19010509, PocketCam, sq905_mode[0], 1, SQ905_FLIP_HORIZ },
- { 0x32010509, Magpix, sq905_mode[0], 1, SQ905_FLIP_HORIZ },
- { 0, Default, sq905_mode[0], 1, SQ905_FLIP_HORIZ | SQ905_FLIP_VERT }
};
/*
@@ -240,7 +237,7 @@ static void sq905_dostream(struct work_s
/* request some data and then read it until we have
* a complete frame. */
- bytes_left = sq905_mode[0].sizeimage + FRAME_HEADER_LEN;
+ bytes_left = dev-cap_mode-sizeimage + FRAME_HEADER_LEN;
header_read = 0;
discarding = 0;
@@ -272,11 +269,18 @@ static void sq905_dostream(struct work_s
packet_type = INTER_PACKET;
}
frame = gspca_get_i_frame(gspca_dev);
- if (frame !discarding)
+ if (frame !discarding) {
gspca_frame_add(gspca_dev, packet_type,
frame, data, data_len);
- else
+ /* If entire frame fits in one packet we still
+ need to add a LAST_PACKET */
+ if ((packet_type == FIRST_PACKET)
+ (bytes_left == 0))
+ gspca_frame_add(gspca_dev, LAST_PACKET,
+ frame, data, 0);
+ } else {
discarding = 1;
+
Re: [RFC 0/5] Sensor drivers for OMAP3430SDP and LDP camera
On Tuesday 03 March 2009, Aguirre Rodriguez, Sergio Alberto wrote: This patch series depends on the following patches: - Add TWL4030 registers, posted by Tuukka Toivonen on March 2nd. http://marc.info/?l=linux-omapm=123597520231668w=2 I'd much rather see these drivers just use the regulator framework to switch any sensor power rails on/off. As with the V4L2 interface changes, the twl4030 regulator support will be in mainline for the 2.6.30 kernels. - Dave -- 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 on proposed patches to mr97310a.c for gspca and v4l
Hans, Jean-Francois, and Kyle,
The proposed patches are not very long, so I will give each of them, with
my comments after each, to explain why I believe that these changes are a
good idea.
First, the patch to libv4lconvert is short and sweet:
contents of file mr97310av4l.patch follow
--
--- mr97310a.c.old 2009-03-01 15:37:38.0 -0600
+++ mr97310a.c.new 2009-02-18 22:39:48.0 -0600
@@ -102,6 +102,9 @@ void v4lconvert_decode_mr97310a(const un
if (!decoder_initialized)
init_mr97310a_decoder();
+ /* remove the header */
+ inp += 12;
+
bitpos = 0;
/* main decoding loop */
- here ends the v4lconvert patch --
The reason I want to do this should be obvious. It is to preserve the
entire header of each frame over in the gspca driver, and to throw it away
over here. The SOF marker FF FF 00 FF 96 is also kept. The reason why all
of this should be kept is that it makes it possible to look at a raw
output and to know if it is exactly aligned or not. Furthermore, the next
byte after the 96 is a code for the compression algorithm used, and the
bytes after that in the header might be useful in the future for better
image processing. In other words, these headers contain information which
might be useful in the future and they should not be jettisoned in the
kernel module.
Now, the kernel module ought to keep and send along the header and SOF
marker instead of throwing them away. This is the topic of the next patch.
It also has the virtue of simplifying and shortening the code in the
module at the same time, because one is not going through contortions to
skip over and throw away some data which ought to be kept anyway.
contents of file mr97310a.patch follow, for gspca/mr97310a.c
--- mr97310a.c.old 2009-02-23 23:59:07.0 -0600
+++ mr97310a.c.new 2009-03-03 17:19:06.0 -0600
@@ -302,21 +302,9 @@ static void sd_pkt_scan(struct gspca_dev
data, n);
sd-header_read = 0;
gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
- len -= sof - data;
- data = sof;
- }
- if (sd-header_read 7) {
- int needed;
-
- /* skip the rest of the header */
- needed = 7 - sd-header_read;
- if (len = needed) {
- sd-header_read += len;
- return;
- }
- data += needed;
- len -= needed;
- sd-header_read = 7;
+ /* keep the header, including sof marker, for coming frame */
+ len -= n;
+ data = sof - sizeof pac_sof_marker;;
}
gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
@@ -337,6 +325,7 @@ static const struct sd_desc sd_desc = {
/* -- module initialisation -- */
static const __devinitdata struct usb_device_id device_table[] = {
{USB_DEVICE(0x08ca, 0x0111)},
+ {USB_DEVICE(0x093a, 0x010f)},
{}
};
MODULE_DEVICE_TABLE(usb, device_table);
end of mr97310a.patch -
You will also notice that I have added a USB ID. As I have mentioned, I
have four cameras with this ID. The story with them is that two of them
will not work at all. The module will not initialize the camera. As far as
the other two of them are concerned, the module and the accompanying
change in libv4lconvert work very well. I have mentioned this previously,
and I did not get any comment about what is good to do. So now I decided
to submit the ID number in the patch.
Theodore Kilgore
--
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] Support alternate resolutions for sq905
On Tue, 3 Mar 2009, Adam Baker wrote: Add support for the alternate resolutions offered by SQ-905 based cameras. As well as 320x240 all cameras can do 160x120 and some can do 640x480. Signed-off-by: Adam Baker li...@baker-net.org.uk --- The patch to detect orientation needs to follow this as that is also simplified by the modified identity check that this introduces. Since you all got a copy of the patch, I don't reproduce it here, munged by a at the beginning of each line. But I would like to add a comment about the 640x480 resolution: It should be obvious that, since the SQ905 cameras use bulk transport and since they do not do compression in streaming mode, the 640x480 streaming is choppy. Nevertheless, those cameras which have big enough sensors to support it can operate at 640x480 in streaming mode. Therefore, it seems appropriate to support that resolution. If nothing else, it would be useful for intermittent or timed frame grabbing, or such like applications. Oh, and it should be needless to say, but in order to satisfy all formalities Signed-off-by: Theodore Kilgore kilg...@auburn.edu -- 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: saa7134 and RDS
Hi,
Am Montag, den 02.03.2009, 13:33 +0900 schrieb Dmitri Belimov:
Hi All.
I want use RDS on our TV cards. But now saa7134 not work with saa6588.
I found this old patch from Hans J. Koch. Why this patch is not in mercurial??
Yes I know that patch for v4l ver.1 and for old kernel. But why not??
v4l has other way for RDS on saa7134 boards?
I think the patch got lost, because it was not clear who should pull it
in. Likely Hartmut or Mauro would have picked it up in 2006 if pinged
directly.
Please try to work with Hans to get it in now. There was also a
suggestion to add a has_rds capability flag and about how to deal with
different RDS decoders later, IIRC.
Cheers,
Hermann
--- from Hans' original posting --
I finally succeeded adding support for the saa6588 RDS decoder to the saa7134
driver. I tested it with a Terratec Cinergy 600, and it seems to work. With
the attached patch applied to saa7134-video.c, I can do
modprobe saa6588 xtal=1
and can then read RDS data from /dev/radio.
I'd be pleased if you could apply that patch.
Cheers,
Hans
Signed-off-by: Hans J. Koch k...@x
--- orig/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-video.c
2006-05-06 13:27:49.0 +0200
+++ mine/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-video.c
2006-05-05 14:38:11.0 +0200
@@ -31,6 +31,7 @@
#include saa7134-reg.h
#include saa7134.h
#include media/v4l2-common.h
+#include media/rds.h
#ifdef CONFIG_VIDEO_V4L1_COMPAT
/* Include V4L1 specific functions. Should be removed soon */
@@ -1374,6 +1375,7 @@ static int video_release(struct inode *i
struct saa7134_fh *fh = file-private_data;
struct saa7134_dev *dev = fh-dev;
unsigned long flags;
+ struct rds_command cmd;
/* turn off overlay */
if (res_check(fh, RESOURCE_OVERLAY)) {
@@ -1409,6 +1411,7 @@ static int video_release(struct inode *i
saa_andorb(SAA7134_OFMT_DATA_B, 0x1f, 0);
saa7134_i2c_call_clients(dev, TUNER_SET_STANDBY, NULL);
+ saa7134_i2c_call_clients(dev, RDS_CMD_CLOSE, cmd);
/* free stuff */
videobuf_mmap_free(fh-cap);
@@ -2284,6 +2287,35 @@ static int radio_ioctl(struct inode *ino
return video_usercopy(inode, file, cmd, arg, radio_do_ioctl);
}
+static ssize_t radio_read(struct file *file, char __user *data,
+ size_t count, loff_t *ppos)
+{
+ struct saa7134_fh *fh = file-private_data;
+ struct saa7134_dev *dev = fh-dev;
+ struct rds_command cmd;
+ cmd.block_count = count/3;
+ cmd.buffer = data;
+ cmd.instance = file;
+ cmd.result = -ENODEV;
+
+ saa7134_i2c_call_clients(dev, RDS_CMD_READ, cmd);
+
+ return cmd.result;
+}
+
+static unsigned int radio_poll(struct file *file, poll_table *wait)
+{
+ struct saa7134_fh *fh = file-private_data;
+ struct saa7134_dev *dev = fh-dev;
+ struct rds_command cmd;
+ cmd.instance = file;
+ cmd.event_list = wait;
+ cmd.result = -ENODEV;
+ saa7134_i2c_call_clients(dev, RDS_CMD_POLL, cmd);
+
+ return cmd.result;
+}
+
static struct file_operations video_fops =
{
.owner= THIS_MODULE,
@@ -2305,6 +2337,8 @@ static struct file_operations radio_fops
.open = video_open,
.release = video_release,
.ioctl= radio_ioctl,
+ .read = radio_read,
+ .poll = radio_poll,
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,11)
.compat_ioctl = v4l_compat_ioctl32,
#endif
--
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: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
Thank you for your kind explanation Hans. Problem is omap3 camera subsystem is making device node for every int device attached to it. Before I have been using v4l2 int device, I implemented S_INPUT/G_INPUT/ENUMINPUT by my own for other CPUs like S3C64XX (just for demo..not opened on public domain yet) In that case, I considered camera interface as a capture device, and every camera devices as input devices for capture device. So using enuminput I could query how many devices do I have for input, and even camera device's name could be get. I made only one device node for camera interface because it was exactly camera interface that I open, not camera module attached on it. Furthermore, CPU's camera video processing H/W cannot process data from multiple cameras at the same time. So no need to make device node for every single camera module attached on it. For these kinds of reason, I think also omap3 camera subsystem should make only one device node for the same category of int device(or subdev for now?). I mean single device node for sensors, single device node for lens controllers, single device node for strobes. I hope I made myself clear. Honestly it is quite hard to explain (even in my language) Cheers, Nate On Tue, Mar 3, 2009 at 4:36 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Tuesday 03 March 2009 06:13:11 DongSoo(Nathaniel) Kim wrote: Thank you for your reply. This is quite confusing because in case of mine, I wanna make switchable between different cameras attached to omap camera interface. Which idea do I have to follow? Comparing with multiple video input devices and multiple cameras attached to single camera interface is giving me no answer. Perhaps multiple cameras with single camera interface couldn't make sense at the first place because single camera interface can go with only one camera module at one time. But we are using like that. I mean dual cameras with single camera interface. There is no choice except that when we are using dual camera without stereo camera controller. If you have multiple inputs (cameras in this case) that the user can choose from, then you need to implement S_INPUT/G_INPUT/ENUMINPUTS. That's what they are there for. Any decent V4L2 app should support these ioctls. By the way, I cannot find any API documents about VIDIOC_INT_S_VIDEO_ROUTING but it seems to be all about how to route between input device with output device. The description of this internal ioctl is in v4l2-common.h. It is used to tell the i2c module how it is hooked up to the rest of the system. I.e. what pin(s) is used for the input signal and what pin(s) is used for the output signal. Typically the main v4l2 driver will map a user-level input (as set with VIDIOC_S_INPUT) to the low-level routing information and pass that on to the i2c device using VIDIOC_INT_S_VIDEO_ROUTING. Regards, Hans What exactly I need is how to make switchable with multiple camera as an input for camera interface, which means just about an input device. In my opinion, those are different issues each other..(Am I right?) Cheers, Nate On Tue, Mar 3, 2009 at 12:53 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: Thanks, Vaibhav Hiremath -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of DongSoo(Nathaniel) Kim Sent: Tuesday, March 03, 2009 8:18 AM To: Tuukka.O Toivonen Cc: Aguirre Rodriguez, Sergio Alberto; linux-o...@vger.kernel.org; Ailus Sakari (Nokia-D/Helsinki); Nagalla, Hari Subject: Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver Hi Tuukka, I understand that it is a huge thing to support VIDIOC_S_INPUT. But without that, we don't have any proper V4L2 api to get information about how many devices are attached to camera interface, and names of input devices...and so on. Because VIDIOC_ENUMINPUT and VIDIOC_G_INPUT needs VIDIOC_S_INPUT for prior. Of course we can refer to sysfs, but using only single set of APIs like V4L2 looks more decent. What do you think about this? If you think that it is a big burden, can I make a patch for this? Cheers, [Hiremath, Vaibhav] You may want to refer to the thread on this subject. http://marc.info/?l=linux-omapm=122772175002777w=2 http://marc.info/?l=linux-omapm=122823846806440w=2 Nate On Mon, Feb 23, 2009 at 5:50 PM, Tuukka.O Toivonen tuukka.o.toivo...@nokia.com wrote: On Monday 23 February 2009 10:08:54 ext DongSoo(Nathaniel) Kim wrote: So, logically it does not make sense with making device nodes of every single slave attached with OMAP3camera interface. Because they can't be opened at the same time,even if it is possible it should not work properly. So.. how about making only single device node like /dev/video0 for OMAP3 camera interface and make it switchable through V4L2 API. Like VIDIOC_S_INPUT? You are right that if
Re: [PULL] http://linuxtv.org/hg/~awalls/cx18
On Sun, 01 Mar 2009 22:04:55 -0500 Andy Walls awa...@radix.net wrote: Mauro, Please pull from http://linuxtv.org/hg/~awalls/cx18 for the following cx18: Add interlock so sliced VBI insertion only happens for an MPEG PS cx18: Fix VPS service register code and ensure VBI consistentcy with ivtv Argh! This is really ugly! + +#include linux/ivtv.h /* For IVTV_SLICED_TYPE_* */ + Why do you need to include a header for a device that has nothing to do with cx18? This doesn't belong here... If those VBI parameters should be global to all devices, then it should be, instead, at some subsystem header, and your patch should also touch on the other drivers. 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: [PULL] http://mercurial.intuxication.org/hg/v4l-dvb-commits
On Mon, 2 Mar 2009 13:31:11 -0800 (PST) Trent Piepho xy...@speakeasy.org wrote: Hi Trent, Here's the latest patch for pluto2. It's a much simpler chip than cx18. I've used atomic operations to design a lockless system. Did you have any return about a tester with pluto2? It would be nice to apply this fix, since we've reverted the alternative patch. 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
em28xx problems
Hello Linux media group, I hope I am asking this in the proper place and fashion, if not, please let me know. I have an old USB video capture device that I used some on windows a few years ago and just the other day I found it and tried it on my Mythtv box. It is a Super Digital Video Dazzle Series USB 2.0 Box. It is recognized on my system as a eMPIA Technology, Inc. GrabBeeX+ Video Encoder, the board itself contains a em2800-02 chip as well as a SAA1713H chip, the tuner is a Shengyi Electronics model TSY5311-N. In both Mythtv an Tvtime I have Composite and S-video but the NTSC tuner is not showing up. Here are the relevant lines from Dmesg em28xx v4l2 driver version 0.1.0 loaded em28xx new video device (eb1a:2801): interface 0, class 255 em28xx Has usb audio class em28xx #0: Alternate settings: 4 em28xx #0: Alternate setting 0, max size= 0 em28xx #0: Alternate setting 1, max size= 644 em28xx #0: Alternate setting 2, max size= 1288 em28xx #0: Alternate setting 3, max size= 2580 em28xx #0: em28xx chip ID = 9 saa7115' 2-0025: saa7113 found (1f7113d0e10) @ 0x4a (em28xx #0) tuner' 2-0061: chip found @ 0xc2 (em28xx #0) tuner' 2-0063: chip found @ 0xc6 (em28xx #0) tuner-simple 2-0061: creating new instance tuner-simple 2-0061: type set to 0 (Temic PAL (4002 FH5)) em28xx #0: AC97 command still being executed: not handled properly! em28xx #0: AC97 command still being executed: not handled properly! em28xx #0: AC97 command still being executed: not handled properly! em28xx #0: AC97 command still being executed: not handled properly! em28xx #0: V4L2 device registered as /dev/video0 and /dev/vbi0 em28xx #0: Found eMPIA Technology, Inc. GrabBeeX+ Video Encoder em28xx audio device (eb1a:2801): interface 1, class 1 usbcore: registered new interface driver em28xx usbcore: registered new interface driver snd-usb-audio I see it finds the tuner as a Temic PAL (4002 FH5) which I know is incorrect because it's an NTSC tuner, I did try adding tuner = 69 (Tena TNF 5335 and similar models) to my modeprobe options but this had no effect on the tuner working. (of course I am not sure that is even the correct one to use, I just found 1 reference to it being correct on the web.) Is it possible to get TV working with this device? Thanks, Jim -- 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: Possible omission in v4l2-common.c?
On Tue, Mar 3, 2009 at 5:29 PM, Janne Grunau j...@jannau.net wrote: On Tuesday 03 March 2009 22:18:55 Hans Verkuil wrote: On Tuesday 03 March 2009 13:50:30 Brandon Jenkins wrote: Hello all, I was upgrading drivers this morning to capture the latest changes for the cx18 and I received a merge conflict in v4l2-common.c. In my system, 1 HDPVR and 3 CX18s. The HDPVR sources are 5 weeks old from their last sync up but contain: case V4L2_CID_SHARPNESS: The newer sources do not, but still have reference to sharpness at line 420: case V4L2_CID_SHARPNESS: return Sharpness; Because I don't know which way the code is going (is sharpness in or out) I can't submit a patch, but thought I would raise here. Diff below was pulled from clean clone of v4l-dvb tree. Sharpness is definitely in. This is a bug, please submit this patch with a Signed-off-by line and I'll get it merged. It is and afaik was never handled in v4l2_ctrl_query_fill(), the hdpvr tree adds that. Since I intend request the merge of the driver in a couple of days a seperate patch shouldn't be needed. janne This is interesting to me. I attempted to merge from a clean clone and pull this morning. The only file which failed was v4l2-common.c. Here's the fail marker: local case V4L2_CID_SHARPNESS: === case V4L2_CID_RED_BALANCE: case V4L2_CID_BLUE_BALANCE: case V4L2_CID_GAMMA: other To produce this I did this from a clean start this morning: hg clone http://hg.jannau.net/hdpvr/ cd hdpvr hg pull http://linuxtv.org/hg/v4l-dvb/ hg merge hg commit I did the very same thing last week as well without a fail. Brandon -- 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: [PULL] http://linuxtv.org/hg/~tap/v4l-dvb
On Tue, 3 Mar 2009 13:59:27 -0800 (PST) Trent Piepho xy...@speakeasy.org wrote: 04/04: v4l2: Move code to zero querybuf output struct to v4l2_ioctl http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=d31e6e7a8241 Hmm.. The idea of using this memset seemed interesting: f02233e4 (Trent Piepho 2009-03-03 20:44:45 -0300 974) memset(0, p-bytesused, f02233e4 (Trent Piepho 2009-03-03 20:44:45 -0300 975) sizeof(*p) - offsetof(typeof(*p), bytesused)); But the end result is that, when compiling it on my -git tree, to have those errors with i386: drivers/media/video/v4l2-ioctl.c: In function ‘__video_do_ioctl’: drivers/media/video/v4l2-ioctl.c:974: warning: cast from pointer to integer of different size drivers/media/video/v4l2-ioctl.c:974: warning: cast from pointer to integer of different size drivers/media/video/v4l2-ioctl.c:974: warning: passing argument 2 of ‘__memset_generic’ makes integer from pointer without a cast drivers/media/video/v4l2-ioctl.c:974: warning: passing argument 2 of ‘__memset_generic’ makes integer from pointer without a cast Could you please provide us a fix? 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: RFC on proposed patches to mr97310a.c for gspca and v4l
On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu wrote: Hans, Jean-Francois, and Kyle, The proposed patches are not very long, so I will give each of them, with my comments after each, to explain why I believe that these changes are a good idea. First, the patch to libv4lconvert is short and sweet: contents of file mr97310av4l.patch follow -- --- mr97310a.c.old2009-03-01 15:37:38.0 -0600 +++ mr97310a.c.new2009-02-18 22:39:48.0 -0600 @@ -102,6 +102,9 @@ void v4lconvert_decode_mr97310a(const un if (!decoder_initialized) init_mr97310a_decoder(); + /* remove the header */ + inp += 12; + bitpos = 0; /* main decoding loop */ - here ends the v4lconvert patch -- The reason I want to do this should be obvious. It is to preserve the entire header of each frame over in the gspca driver, and to throw it away over here. The SOF marker FF FF 00 FF 96 is also kept. The reason why all of this should be kept is that it makes it possible to look at a raw output and to know if it is exactly aligned or not. Furthermore, the next byte after the 96 is a code for the compression algorithm used, and the bytes after that in the header might be useful in the future for better image processing. In other words, these headers contain information which might be useful in the future and they should not be jettisoned in the kernel module. No complaints here. I copied off of the pac207 driver, thinking that one compression format == one pixel format and that all mr97310a cameras use the same compression. I was hesitant to say that the mr97310a pixel format can correspond to multiple compression formats, especially since I only have one such camera and I don't know if it's preferred to use multiple pixel formats for this reason. From what I understand, sending the frame header to userspace solves at least two problems (if indeed the compression is specified in the header): * One frame may be compressed and the next frame isn't, or the next frame uses a different compression. * Two cameras with the same vendor/product ID use different compression formats. Distinguishing the two cameras in the kernel driver could be messy. Just a random thought, but maybe the pac207 driver can benefit from such a change as well? -Kyle -- 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 on proposed patches to mr97310a.c for gspca and v4l
On Tue, 3 Mar 2009, Kyle Guinn wrote: On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu wrote: Hans, Jean-Francois, and Kyle, The proposed patches are not very long, so I will give each of them, with my comments after each, to explain why I believe that these changes are a good idea. First, the patch to libv4lconvert is short and sweet: contents of file mr97310av4l.patch follow -- --- mr97310a.c.old 2009-03-01 15:37:38.0 -0600 +++ mr97310a.c.new 2009-02-18 22:39:48.0 -0600 @@ -102,6 +102,9 @@ void v4lconvert_decode_mr97310a(const un if (!decoder_initialized) init_mr97310a_decoder(); + /* remove the header */ + inp += 12; + bitpos = 0; /* main decoding loop */ - here ends the v4lconvert patch -- The reason I want to do this should be obvious. It is to preserve the entire header of each frame over in the gspca driver, and to throw it away over here. The SOF marker FF FF 00 FF 96 is also kept. The reason why all of this should be kept is that it makes it possible to look at a raw output and to know if it is exactly aligned or not. Furthermore, the next byte after the 96 is a code for the compression algorithm used, and the bytes after that in the header might be useful in the future for better image processing. In other words, these headers contain information which might be useful in the future and they should not be jettisoned in the kernel module. No complaints here. I copied off of the pac207 driver, thinking that one compression format == one pixel format and that all mr97310a cameras use the same compression. I was hesitant to say that the mr97310a pixel format can correspond to multiple compression formats, especially since I only have one such camera and I don't know if it's preferred to use multiple pixel formats for this reason. Well, it is a fact that different compression formats are used by some cameras. First, the two 0x093a:0x010f cameras which I have that do *not* work with this module actually do use different compression algorithms. The proof is that what will convert the raw files of one of them, will not work on the other. The only place this is visible is in the header of the raw file (see previous discussion about this on the list). Well, OK, these cameras do not work. But then there are the 0x093a:0x010e cameras. They work very nicely with all of your code, up to the point that they use a different compressed format for the raw output and the frames come out looking wrong. Again, the only place this is marked is there is an indicator byte for the compression algorithm, and it is in the header. From what I understand, sending the frame header to userspace solves at least two problems (if indeed the compression is specified in the header): It is. Really. * One frame may be compressed and the next frame isn't, or the next frame uses a different compression. These are very unlikely scenarios for a webcam. They assuredly do occur with still cameras, true. At least, one finds that the still camera will support a compressed mode, and an uncompressed mode. And, yes, the different kinds can be all mixed together. For, the user can reset the compression setting before each picture is shot. * Two cameras with the same vendor/product ID use different compression formats. Distinguishing the two cameras in the kernel driver could be messy. Well, sending the header along takes care of that. Once it is known how to decompress them, all that one needs to do is to look at the telltale byte from the header, and one knows which algorithm to use. Simple, actually. Just a random thought, but maybe the pac207 driver can benefit from such a change as well? Probably. It just isn't my business. I would really be curious what those bytes are that are in the pac207 header, too, for comparison purposes and because someone ought to make a record of these things. Thus, if it were left to me I would probably rewrite the pac_common.h file change all apps which use it, in accord with the changes there and in accord with what I proposed here. But those would be too many changes which involve too many people at once, and something can go wrong when one does that. So better just to change the one driver I am interested in, hoping that you would not mind, and because I have a couple of cameras that I could test it with and I can say it works well after the changes. Why would I change pac_common.h? Well, the sof marker should not be tossed, either, IMHO, because it is after all an sof marker. It is very comforting to be able to look at a raw output and to know for certain that at least it starts out right because it begins with an sof marker. One knows then that things are going well. That after all is part of the reason an sof marker is put there in the first place. To know where the
Re: [RFC 0/5] Sensor drivers for OMAP3430SDP and LDP camera
Aguirre Rodriguez, Sergio Alberto wrote: This patch series depends on the following patches: - Add TWL4030 registers, posted by Tuukka Toivonen on March 2nd. - OMAP3 ISP and camera drivers patch series, posted by Sakari Ailus on March 3rd. (Please follow his instructions to pull from gitorious.org server) This has been tested with: - SDP3430-VG5.0.1 with OMAP3430-ES3.1 daughter board upgrade. - Camkit V3.0.1 with MT9P012 and OV3640 sensors - LDP with OV3640 sensor Sergio Aguirre (5): MT9P012: Add driver DW9710: Add driver OV3640: Add driver Hi, Sergio, You forgot to send the 3rd patch, OV3640: Add driver. Stanley. OMAP3430SDP: Add support for Camera Kit v3 LDP: Add support for built-in camera -- 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/5] Sensor drivers for OMAP3430SDP and LDP camera
On Wednesday 04 March 2009 00:16:47 Aguirre Rodriguez, Sergio Alberto wrote: -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, March 03, 2009 4:47 PM To: Aguirre Rodriguez, Sergio Alberto Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Sakari Ailus; Tuukka.O Toivonen; Hiroshi DOYU; DongSoo(Nathaniel) Kim; MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth Subject: Re: [RFC 0/5] Sensor drivers for OMAP3430SDP and LDP camera On Tuesday 03 March 2009 21:44:12 Aguirre Rodriguez, Sergio Alberto wrote: This patch series depends on the following patches: - Add TWL4030 registers, posted by Tuukka Toivonen on March 2nd. - OMAP3 ISP and camera drivers patch series, posted by Sakari Ailus on March 3rd. (Please follow his instructions to pull from gitorious.org server) Sergio, Sakari, I'm feeling quite uncomfortable about this series with regards to the use of the v4l2-int API instead of v4l2_subdev. I know that it is on the TODO list, but every driver that is merged that uses v4l2-int will later mean extra work. I and others have been working very hard to get the existing ioctl-based i2c modules converted in time for the 2.6.30 merge window. It looks like I'll be able to have it done in time (fingers crossed :-) ). So it is rather sad to see new modules that do not yet use it. Right now the v4l2_device and v4l2_subdev framework is pretty basic and so the amount of work to do the conversion is still limited, but once I've finished my initial conversion I'll be adding lots more features, do cleanups, and generally improve the framework substantially. Any existing modules that use v4l2_device and v4l2_subdev will be updated by me. But I'm not going to do that for modules using v4l2-int, that will be the responsibility of the module's author when he converts it to v4l2_subdev. So the longer you wait, the more work that will be. I *strongly* recommend that the conversion to the new framework is done first. I know it might delay inclusion of some drivers, but my expectation based on all the other conversions I've done until now is that it will actually simplify the drivers. My experiences with it have been uniformly positive and it should be possible to use it as well with the ISP module or other logical sub-devices. There are lots of interesting possibilities there that you do not have with v4l2-int. Hans, I agree that we need to head for migration asap, but we hadn't had a chance to begin on this as some other higher priority issues were (and some still are) showing up. Anyways, can you please point me to the latest version of the v4l2_subdev documentation so we can begin properly working on this? The latest version can always be found here: http://linuxtv.org/hg/v4l-dvb/raw-file/tip/linux/Documentation/video4linux/v4l2-framework.txt Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
On Wednesday 04 March 2009 01:42:13 DongSoo(Nathaniel) Kim wrote: Thank you for your kind explanation Hans. Problem is omap3 camera subsystem is making device node for every int device attached to it. That's wrong. Multiple devices should only be created if they can all be used at the same time. Otherwise there should be just one device that uses S_INPUT et al to select between the inputs. BTW, do I understand correctly that e.g. lens drivers also get their own /dev/videoX node? Please tell me I'm mistaken! Since that would be so very wrong. Before I have been using v4l2 int device, I implemented S_INPUT/G_INPUT/ENUMINPUT by my own for other CPUs like S3C64XX (just for demo..not opened on public domain yet) In that case, I considered camera interface as a capture device, and every camera devices as input devices for capture device. So using enuminput I could query how many devices do I have for input, and even camera device's name could be get. This sort of information has to come from the platform, not from drivers. It is dangerous to rely on what i2c modules tell you what their inputs are. E.g. suppose you have two sensors whose input is combined by an FPGA into some sort of 3D format? Two sensors, but only one input. The platform data is where such information should be stored since only at that level is the whole board layout known. I made only one device node for camera interface because it was exactly camera interface that I open, not camera module attached on it. Furthermore, CPU's camera video processing H/W cannot process data from multiple cameras at the same time. So no need to make device node for every single camera module attached on it. Correct. For these kinds of reason, I think also omap3 camera subsystem should make only one device node for the same category of int device(or subdev for now?). I mean single device node for sensors, single device node for lens controllers, single device node for strobes. I hope I made myself clear. Honestly it is quite hard to explain (even in my language) You are completely right, except that this info should come from the platform. I hope that the conversion to v4l2_subdev will take place soon. You are basically stuck in a technological dead-end :-( Regards, Hans Cheers, Nate On Tue, Mar 3, 2009 at 4:36 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Tuesday 03 March 2009 06:13:11 DongSoo(Nathaniel) Kim wrote: Thank you for your reply. This is quite confusing because in case of mine, I wanna make switchable between different cameras attached to omap camera interface. Which idea do I have to follow? Comparing with multiple video input devices and multiple cameras attached to single camera interface is giving me no answer. Perhaps multiple cameras with single camera interface couldn't make sense at the first place because single camera interface can go with only one camera module at one time. But we are using like that. I mean dual cameras with single camera interface. There is no choice except that when we are using dual camera without stereo camera controller. If you have multiple inputs (cameras in this case) that the user can choose from, then you need to implement S_INPUT/G_INPUT/ENUMINPUTS. That's what they are there for. Any decent V4L2 app should support these ioctls. By the way, I cannot find any API documents about VIDIOC_INT_S_VIDEO_ROUTING but it seems to be all about how to route between input device with output device. The description of this internal ioctl is in v4l2-common.h. It is used to tell the i2c module how it is hooked up to the rest of the system. I.e. what pin(s) is used for the input signal and what pin(s) is used for the output signal. Typically the main v4l2 driver will map a user-level input (as set with VIDIOC_S_INPUT) to the low-level routing information and pass that on to the i2c device using VIDIOC_INT_S_VIDEO_ROUTING. Regards, Hans What exactly I need is how to make switchable with multiple camera as an input for camera interface, which means just about an input device. In my opinion, those are different issues each other..(Am I right?) Cheers, Nate On Tue, Mar 3, 2009 at 12:53 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: Thanks, Vaibhav Hiremath -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of DongSoo(Nathaniel) Kim Sent: Tuesday, March 03, 2009 8:18 AM To: Tuukka.O Toivonen Cc: Aguirre Rodriguez, Sergio Alberto; linux-o...@vger.kernel.org; Ailus Sakari (Nokia-D/Helsinki); Nagalla, Hari Subject: Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver Hi Tuukka, I understand that it is a huge thing to support VIDIOC_S_INPUT. But without that, we don't have any proper V4L2 api to get information about how many devices are attached to camera
Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
On Wednesday 04 March 2009 09:39:48 ext Hans Verkuil wrote: BTW, do I understand correctly that e.g. lens drivers also get their own /dev/videoX node? Please tell me I'm mistaken! Since that would be so very wrong. You're mistaken :) With the v4l2-int-interface/omap34xxcam camera driver one device node consists of all slaves (sensor, lens, flash, ...) making up the complete camera device. I hope that the conversion to v4l2_subdev will take place soon. You are basically stuck in a technological dead-end :-( Ok :( - Tuukka -- 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
