gmane.comp.video.video4linux

[PATCH 1/2] Unuse ov772x_default_regs in ov772x driver

Kuninori Morimoto — 2008-12-02T00:29:43

Signed-off-by: Kuninori Morimoto renesas.com> --- this patch came from "Change device ID selection method on ov772x driver" yesterday drivers/media/video/ov772x.c | 21 +++------------------ 1 files changed, 3 insertions(+), 18 deletions(-) diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c index d3b54a4..2b8d72d 100644 --- a/drivers/media/video/ov772x.c +++ b/drivers/media/video/ov772x.c < at >< at > -378,30 +378,17 < at >< at > struct ov772x_priv { #define ENDMARKER { 0xff, 0xff } -static const struct regval_list ov772x_default_regs[] = -{ -{ COM3, 0x00 }, -{ COM4, PLL_4x | 0x01 }, -{ 0x16, 0x00 }, /* Mystery */ -{ COM11, 0x10 }, /* Mystery */ -{ 0x28, 0x00 }, /* Mystery */ -{ HREF, 0x00 }, -{ COM13, 0xe2 }, /* Mystery */ -{ AREF0, 0xef }, -{ AREF2, 0x60 }, -{ AREF6, 0x7a }, -ENDMARKER, -}; - /* * register setting for color format */ static const struct regval_list ov772x_RGB555_regs[] = { +{ COM3, 0x00 }, { COM7, FMT_RGB555 | OFMT_RGB }, ENDMARKER, }; static const struct regval_list ov772x_RGB565_regs[] = { +{ COM3, 0x00 }, { COM7, FMT_RGB565 | OFMT_RGB }, ENDMARKER, }; < at >< at > -413,6 +400,7 < at >< at > static const struct regval_list ov772x_YYUV_regs[] = { }; static const struct regval_list ov772x_UVYY_regs[] = { +{ COM3, 0x00 }, { COM7, OFMT_YUV }, ENDMARKER, }; < at >< at > -634,9 +622,6 < at >< at > static int ov772x_start_capture(struct soc_camera_device *icd) * reset hardware */ ov772x_reset(priv->client); -ret = ov772x_write_array(priv->client, ov772x_default_regs); -if (ret < 0) -goto start_end; /* * set color format

[PATCH 2/2] Change device ID selection method on ov772x driver

Kuninori Morimoto — 2008-12-02T00:34:14

Signed-off-by: Kuninori Morimoto renesas.com> --- this patch came from "Change device ID selection method on ov772x driver" yesterday drivers/media/video/ov772x.c | 27 +++++++++++++++++++++------ include/media/v4l2-chip-ident.h | 2 +- 2 files changed, 22 insertions(+), 7 deletions(-) diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c index 2b8d72d..f417df1 100644 --- a/drivers/media/video/ov772x.c +++ b/drivers/media/video/ov772x.c < at >< at > -346,6 +346,12 < at >< at > #define OP_SWAP_RGB 0x00000002 /* + * ID + */ +#define OV7720 0x7720 +#define VERSION(pid, ver) ((pid<<8)|(ver&0xFF)) + +/* * struct */ struct regval_list { < at >< at > -374,6 +380,7 < at >< at > struct ov772x_priv { struct soc_camera_device icd; const struct ov772x_color_format *fmt; const struct ov772x_win_size *win; +int model; }; #define ENDMARKER { 0xff, 0xff } < at >< at > -702,7 +709,9 < at >< at > static unsigned long ov772x_query_bus_param(struct soc_camera_device *icd) static int ov772x_get_chip_id(struct soc_camera_device *icd, struct v4l2_chip_ident *id) { -id->ident = V4L2_IDENT_OV772X; +struct ov772x_priv *priv = container_of(icd, struct ov772x_priv, icd); + +id->ident = priv->model; id->revision = 0; return 0; < at >< at > -796,6 +805,7 < at >< at > static int ov772x_video_probe(struct soc_camera_device *icd) { struct ov772x_priv *priv = container_of(icd, struct ov772x_priv, icd); u8 pid, ver; +const char *devname; /* * We must have a parent by now. And it cannot be a wrong one. < at >< at > -822,15 +832,21 < at >< at > static int ov772x_video_probe(struct soc_camera_device *icd) */ pid = i2c_smbus_read_byte_data(priv->client, PID); ver = i2c_smbus_read_byte_data(priv->client, VER); -if (pid != 0x77 || - ver != 0x21) { + +switch (VERSION(pid, ver)) { +case OV7720: +devname = "ov7720"; +priv->model = V4L2_IDENT_OV7720; +break; +default: dev_err(&icd->dev, "Product ID error %x:%x\n", pid, ver); return -ENODEV; } dev_info(&icd->dev, - "ov772x Product ID %0x:%0x Manufacturer ID %x:%x\n", + "%s Product ID %0x:%0x Manufacturer ID %x:%x\n", + devname, pid, ver, i2c_smbus_read_byte_data(priv->client, MIDH), < at >< at > -921,7 +937,7 < at >< at > static int ov772x_remove(struct i2c_client *client) } static const struct i2c_device_id ov772x_id[] = { -{"ov772x", 0}, +{ "ov772x", 0 }, { } }; MODULE_DEVICE_TABLE(i2c, ov772x_id); < at >< at > -941,7 +957,6 < at >< at > static struct i2c_driver ov772x_i2c_driver = { static int __init ov772x_module_init(void) { -printk(KERN_INFO "ov772x driver\n"); return i2c_add_driver(&ov772x_i2c_driver); } diff --git a/include/media/v4l2-chip-ident.h b/include/media/v4l2-chip-ident.h index bfe5142..456ac0d 100644 --- a/include/media/v4l2-chip-ident.h +++ b/include/media/v4l2-chip-ident.h < at >< at > -60,7 +60,7 < at >< at > enum { /* OmniVision sensors: reserved range 250-299 */ V4L2_IDENT_OV7670 = 250, -V4L2_IDENT_OV772X = 251, +V4L2_IDENT_OV7720 = 251, /* Conexant MPEG encoder/decoders: reserved range 410-420 */ V4L2_IDENT_CX23415 = 415,

Re: [PATCH] Add ov7725 ov7720 support to ov772x driver

2008-12-02T00:18:13

Dear Guennadi Thank you for checking patch. Yes. I was going to send this patch to linux-sh ML when Paul's git has ov772x driver. Should I send it Now ? /Morimoto -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 1/2] Change device ID selection method on ov772x driver

2008-12-02T00:13:02

Dear Guennadi Thank you for checking patch (snip) Indeed It is not unrelated to the ID-change. But it is related to ov7720 driver (and for extension). Because my board document said our board has ov7720 camera device. And I had created ov772x driver by using ov7720 document. But our board realy has ov7725 camera device. This is the reason why ov772x_default_regs had *Mystery* settings. OK I will re-create this patch like this 1) Unuse ov772x_default_regs in ov772x driver 2) Change device ID selection method on ov772x driver 3) Add ov7725 support for ov772x driver Is it OK ? /Morimoto -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng

Andy Walls — 2008-12-02T00:02:53

Only if you want small successes (or failures) instead of spectacular failures. :) http://en.wikipedia.org/wiki/Gall's_law Regards, Andy -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list

Re: minimum v4l2 api - framework

CityK — 2008-12-01T22:24:23

The bread crumbs start on the front page via the "Important Notice", but anyhow, to cut out the chase: http://www.linuxtv.org/wiki/index.php/Main_Page > User Section > Having Trouble? > V4L Test Suite -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list

RE: Hauppauge WinTV USB Model 566 PAL-I

Chris Grove — 2008-12-01T22:18:02

-----Original Message----- From: Thierry Merle [mailto:thierry.merle< at >free.fr] Sent: 01 December 2008 21:06 To: Chris Grove Subject: Re: Hauppauge WinTV USB Model 566 PAL-I Chris Grove wrote: help. I found the audio-over-usb code (see attached). The code may need some cleanups and can cause kernel oops. The USB snoops need to be analyzed. Can you put it on a site so that I can download it? Nevertheless you can read what I wrote when I was programming the audio-over-usb driver here: http://thierry.merle.free.fr/articles.php?lng=en&pg=82 The page was translated to English using google translate so there may be some problems of understanding :) For some more information about the usbvision chip, I wrote a page here: http://thierry.merle.free.fr/articles.php?lng=en&pg=68 As a first step, I will look at the register accesses. They begin with a line like this: 00000000: 00000000: 42 33 00 00 With the datasheet I can understand what the windows driver is setting. [SNIP] For example here you have a register programming #07 (SER_MODE from the NT1004 datasheet). Value is 0x30 (TransferBufferMDL line). Means MODE=3. This is just for the example, this one is not interesting. There are other registers more interesting but I should have the complete log to find out. You may have sent me the sufficient data to investigate but in doubt give me the complete logs. Of course you can look at the problem if you are interested. Thanks Thierry Hi Thierry, Thanks for the links to you code, I'll download it and have a look. Here's hoping I can work out what's going on in it. I've uploaded the whole of the log to my skydrive, the link is below. http://cid-19380f9184511dde.skydrive.live.com/browse.aspx/Public To be honest I'm only a learner when it comes to linux and c++ programming, I'm more of a basic programmer so I need all the help I can get my hands on. Thanks in advance for all your help. Chris. -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list

[GIT PATCHES for 2.6.28] V4L/DVB fixes

Mauro Carvalho Chehab — 2008-12-01T22:08:53

Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git for_linus For the following driver fixes: - af9015: don't reconnect device in USB-bus - dib0700: make remote control support work with firmware v1.20 - dm1105: Fix section mismatch - dvb-ttusb-budget: Add NULL pointer validation - dvb-ttusb-budget: Add validation for ttusb_alloc_iso_urbs - em28xx: Avoid i2c register error for boards without eeprom - em28xx: Avoid memory leaks if registration fails - em28xx: avoid allocating/dealocating memory on every control urb - em28xx: avoid having two concurrent control URB's - em28xx: fix oops audio - em28xx: fix compile warning - em28xx: fix a race condition with hald - em28xx: make em28xx aux audio input work - em28xx: Make sure the i2c gate is open before powering down tuner - em28xx-alsa: implement another locking schema - gspca: Memory leak when disconnect while streaming. - gspca: Lock the subdrivers via module_get/put. - gspca: Move the video device to a separate area. - s2255drv: fix firmware test on big-endian - sms1xxx: use new firmware for Hauppauge WinTV MiniStick - ttusb_dec: Add NULL pointer validation - ttusb_dec: fix memory leak - usb-urb: fix memory leak Also, one DVB api fix: - Make s2api work for ATSC Cheers, Mauro. --- drivers/media/dvb/dm1105/dm1105.c | 2 +- drivers/media/dvb/dvb-core/dvb_frontend.c | 5 +- drivers/media/dvb/dvb-usb/af9015.c | 8 +- drivers/media/dvb/dvb-usb/dib0700.h | 5 +- drivers/media/dvb/dvb-usb/dib0700_core.c | 16 +++ drivers/media/dvb/dvb-usb/dib0700_devices.c | 139 ++++++++++++++++++++- drivers/media/dvb/dvb-usb/usb-urb.c | 19 ++- drivers/media/dvb/siano/sms-cards.c | 2 +- drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c | 15 ++- drivers/media/dvb/ttusb-dec/ttusb_dec.c | 7 + drivers/media/video/em28xx/em28xx-audio.c | 33 +++--- drivers/media/video/em28xx/em28xx-core.c | 58 ++++++---- drivers/media/video/em28xx/em28xx-i2c.c | 10 +- drivers/media/video/em28xx/em28xx-video.c | 140 ++++++++++++--------- drivers/media/video/em28xx/em28xx.h | 6 + drivers/media/video/gspca/conex.c | 3 + drivers/media/video/gspca/finepix.c | 8 ++ drivers/media/video/gspca/gspca.c | 56 +++++---- drivers/media/video/gspca/gspca.h | 6 +- drivers/media/video/gspca/pac7311.c | 3 + drivers/media/video/gspca/spca501.c | 3 + drivers/media/video/gspca/spca505.c | 4 + drivers/media/video/gspca/spca561.c | 3 + drivers/media/video/gspca/vc032x.c | 3 + drivers/media/video/gspca/zc3xx.c | 3 + drivers/media/video/s2255drv.c | 2 +- 26 files changed, 410 insertions(+), 149 deletions(-) Devin Heitmueller (4): V4L/DVB (9631): Make s2api work for ATSC support V4L/DVB (9632): make em28xx aux audio input work V4L/DVB (9634): Make sure the i2c gate is open before powering down tuner V4L/DVB (9639): Make dib0700 remote control support work with firmware v1.20 Douglas Schilling Landgraf (6): V4L/DVB (9601): ttusb_dec: Add NULL pointer validation V4L/DVB (9602): dvb-ttusb-budget: Add NULL pointer validation V4L/DVB (9603): dvb-ttusb-budget: Add validation for ttusb_alloc_iso_urbs V4L/DVB (9604): ttusb_dec: fix memory leak V4L/DVB (9605): usb-urb: fix memory leak V4L/DVB (9743): em28xx: fix oops audio Hans Verkuil (1): V4L/DVB (9748): em28xx: fix compile warning Harvey Harrison (1): V4L/DVB (9635): v4l: s2255drv fix firmware test on big-endian Igor M. Liplianin (1): V4L/DVB (9608): Fix section mismatch warning for dm1105 during make Jean-Francois Moine (3): V4L/DVB (9689): gspca: Memory leak when disconnect while streaming. V4L/DVB (9690): gspca: Lock the subdrivers via module_get/put. V4L/DVB (9691): gspca: Move the video device to a separate area. Jose Alberto Reguero (1): V4L/DVB (9664): af9015: don't reconnect device in USB-bus Mauro Carvalho Chehab (7): V4L/DVB (9627): em28xx: Avoid i2c register error for boards without eeprom V4L/DVB (9645): em28xx: Avoid memory leaks if registration fails V4L/DVB (9646): em28xx: avoid allocating/dealocating memory on every control urb V4L/DVB (9647): em28xx: void having two concurrent control URB's V4L/DVB (9668): em28xx: fix a race condition with hald V4L/DVB (9742): em28xx-alsa: implement another locking schema em28xx: remove backward compat macro added on a previous fix Michael Krufky (1): V4L/DVB (9732): sms1xxx: use new firmware for Hauppauge WinTV MiniStick --------------------------------------------------- V4L/DVB development is hosted at http://linuxtv.org -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list

[PATCH] mt9m111: Add automatic white balance control

Robert Jarzmik — 2008-12-01T21:15:58

Signed-off-by: Robert Jarzmik free.fr> --- drivers/media/video/mt9m111.c | 28 +++++++++++++++++++++++++++- 1 files changed, 27 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c index 9b9b377..208ec6c 100644 --- a/drivers/media/video/mt9m111.c +++ b/drivers/media/video/mt9m111.c < at >< at > -90,7 +90,7 < at >< at > #define MT9M111_OUTPUT_FORMAT_CTRL2_B0x19b #define MT9M111_OPMODE_AUTOEXPO_EN(1 << 14) - +#define MT9M111_OPMODE_AUTOWHITEBAL_EN(1 << 1) #define MT9M111_OUTFMT_PROCESSED_BAYER(1 << 14) #define MT9M111_OUTFMT_BYPASS_IFP(1 << 10) < at >< at > -163,6 +163,7 < at >< at > struct mt9m111 { unsigned int swap_rgb_red_blue:1; unsigned int swap_yuv_y_chromas:1; unsigned int swap_yuv_cb_cr:1; +unsigned int autowhitebalance:1; }; static int reg_page_map_set(struct i2c_client *client, const u16 reg) < at >< at > -701,6 +702,23 < at >< at > static int mt9m111_set_autoexposure(struct soc_camera_device *icd, int on) return ret; } + +static int mt9m111_set_autowhitebalance(struct soc_camera_device *icd, int on) +{ +struct mt9m111 *mt9m111 = container_of(icd, struct mt9m111, icd); +int ret; + +if (on) +ret = reg_set(OPER_MODE_CTRL, MT9M111_OPMODE_AUTOWHITEBAL_EN); +else +ret = reg_clear(OPER_MODE_CTRL, MT9M111_OPMODE_AUTOWHITEBAL_EN); + +if (!ret) +mt9m111->autowhitebalance = on; + +return ret; +} + static int mt9m111_get_control(struct soc_camera_device *icd, struct v4l2_control *ctrl) { < at >< at > -737,6 +755,9 < at >< at > static int mt9m111_get_control(struct soc_camera_device *icd, case V4L2_CID_EXPOSURE_AUTO: ctrl->value = mt9m111->autoexposure; break; +case V4L2_CID_AUTO_WHITE_BALANCE: +ctrl->value = mt9m111->autowhitebalance; +break; } return 0; } < at >< at > -770,6 +791,9 < at >< at > static int mt9m111_set_control(struct soc_camera_device *icd, case V4L2_CID_EXPOSURE_AUTO: ret = mt9m111_set_autoexposure(icd, ctrl->value); break; +case V4L2_CID_AUTO_WHITE_BALANCE: +ret = mt9m111_set_autowhitebalance(icd, ctrl->value); +break; default: ret = -EINVAL; } < at >< at > -788,6 +812,7 < at >< at > static int mt9m111_restore_state(struct soc_camera_device *icd) mt9m111_set_flip(icd, mt9m111->vflip, MT9M111_RMB_MIRROR_ROWS); mt9m111_set_global_gain(icd, icd->gain); mt9m111_set_autoexposure(icd, mt9m111->autoexposure); +mt9m111_set_autowhitebalance(icd, mt9m111->autowhitebalance); return 0; } < at >< at > -882,6 +907,7 < at >< at > static int mt9m111_video_probe(struct soc_camera_device *icd) goto eisis; mt9m111->autoexposure = 1; +mt9m111->autowhitebalance = 1; mt9m111->swap_rgb_even_odd = 1; mt9m111->swap_rgb_red_blue = 1;

Re: About CITOR register value for pxa_camera

Robert Jarzmik — 2008-12-01T21:13:57

Tested-by: Robert Jarzmik free.fr> The only comment I would have is about suspend/resume, when lcd clock rate might have changed. But since the patch doesn't either break or improve the legacy behaviour, I'm for leaving it as it is. Cheers. -- Robert -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH, RFC] mt9m111: allow data to be received on pixelclock falling edge?

Guennadi Liakhovetski — 2008-12-01T20:54:17

Hi Antonio, On Wed, 12 Nov 2008, Antonio Ospite wrote: Could you test the patch below? It applies on top of all my patches I pushed today plus a couple more that are still to be pushed... But maybe you can apply it to linux-next manually. You just need the parts for soc_camera.h and for mt9m111. And then you need to add to your struct soc_camera_link in platform data: .flags = SOCAM_SENSOR_INVERT_PCLK, Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c index 0bcfef7..b58f0f8 100644 --- a/drivers/media/video/mt9m001.c +++ b/drivers/media/video/mt9m001.c < at >< at > -272,17 +272,16 < at >< at > static int mt9m001_set_bus_param(struct soc_camera_device *icd, static unsigned long mt9m001_query_bus_param(struct soc_camera_device *icd) { struct mt9m001 *mt9m001 = container_of(icd, struct mt9m001, icd); -unsigned int width_flag = SOCAM_DATAWIDTH_10; +struct soc_camera_link *icl = mt9m001->client->dev.platform_data; +/* MT9M001 has all capture_format parameters fixed */ +unsigned long flags = SOCAM_DATAWIDTH_10 | SOCAM_PCLK_SAMPLE_RISING | +SOCAM_HSYNC_ACTIVE_HIGH | SOCAM_VSYNC_ACTIVE_HIGH | +SOCAM_MASTER; if (bus_switch_possible(mt9m001)) -width_flag |= SOCAM_DATAWIDTH_8; +flags |= SOCAM_DATAWIDTH_8; -/* MT9M001 has all capture_format parameters fixed */ -return SOCAM_PCLK_SAMPLE_RISING | -SOCAM_HSYNC_ACTIVE_HIGH | -SOCAM_VSYNC_ACTIVE_HIGH | -SOCAM_MASTER | -width_flag; +return soc_camera_apply_sensor_flags(icl, flags); } static int mt9m001_set_fmt(struct soc_camera_device *icd, < at >< at > -578,6 +577,7 < at >< at > static int mt9m001_set_control(struct soc_camera_device *icd, struct v4l2_contro static int mt9m001_video_probe(struct soc_camera_device *icd) { struct mt9m001 *mt9m001 = container_of(icd, struct mt9m001, icd); +struct soc_camera_link *icl = mt9m001->client->dev.platform_data; s32 data; int ret; < at >< at > -600,7 +600,7 < at >< at > static int mt9m001_video_probe(struct soc_camera_device *icd) case 0x8421: mt9m001->model = V4L2_IDENT_MT9M001C12ST; icd->formats = mt9m001_colour_formats; -if (mt9m001->client->dev.platform_data) +if (gpio_is_valid(icl->gpio)) icd->num_formats = ARRAY_SIZE(mt9m001_colour_formats); else icd->num_formats = 1; < at >< at > -608,7 +608,7 < at >< at > static int mt9m001_video_probe(struct soc_camera_device *icd) case 0x8431: mt9m001->model = V4L2_IDENT_MT9M001C12STM; icd->formats = mt9m001_monochrome_formats; -if (mt9m001->client->dev.platform_data) +if (gpio_is_valid(icl->gpio)) icd->num_formats = ARRAY_SIZE(mt9m001_monochrome_formats); else icd->num_formats = 1; diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c index b4a238f..b0e6046 100644 --- a/drivers/media/video/mt9m111.c +++ b/drivers/media/video/mt9m111.c < at >< at > -415,9 +415,13 < at >< at > static int mt9m111_stop_capture(struct soc_camera_device *icd) static unsigned long mt9m111_query_bus_param(struct soc_camera_device *icd) { -return SOCAM_MASTER | SOCAM_PCLK_SAMPLE_RISING | +struct mt9m111 *mt9m111 = container_of(icd, struct mt9m111, icd); +struct soc_camera_link *icl = mt9m111->client->dev.platform_data; +unsigned long flags = SOCAM_MASTER | SOCAM_PCLK_SAMPLE_RISING | SOCAM_HSYNC_ACTIVE_HIGH | SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_DATAWIDTH_8; + +return soc_camera_apply_sensor_flags(icl, flags); } static int mt9m111_set_bus_param(struct soc_camera_device *icd, unsigned long f) diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c index 3a39f02..3b3a6a0 100644 --- a/drivers/media/video/mt9v022.c +++ b/drivers/media/video/mt9v022.c < at >< at > -273,6 +273,7 < at >< at > static int mt9v022_set_bus_param(struct soc_camera_device *icd, unsigned long flags) { struct mt9v022 *mt9v022 = container_of(icd, struct mt9v022, icd); +struct soc_camera_link *icl = mt9v022->client->dev.platform_data; unsigned int width_flag = flags & SOCAM_DATAWIDTH_MASK; int ret; u16 pixclk = 0; < at >< at > -296,6 +297,8 < at >< at > static int mt9v022_set_bus_param(struct soc_camera_device *icd, mt9v022->datawidth = width_flag == SOCAM_DATAWIDTH_8 ? 8 : 10; } +flags = soc_camera_apply_sensor_flags(icl, flags); + if (flags & SOCAM_PCLK_SAMPLE_RISING) pixclk |= 0x10; < at >< at > -690,6 +693,7 < at >< at > static int mt9v022_set_control(struct soc_camera_device *icd, static int mt9v022_video_probe(struct soc_camera_device *icd) { struct mt9v022 *mt9v022 = container_of(icd, struct mt9v022, icd); +struct soc_camera_link *icl = mt9v022->client->dev.platform_data; s32 data; int ret; < at >< at > -725,7 +729,7 < at >< at > static int mt9v022_video_probe(struct soc_camera_device *icd) ret = reg_write(icd, MT9V022_PIXEL_OPERATION_MODE, 4 | 0x11); mt9v022->model = V4L2_IDENT_MT9V022IX7ATC; icd->formats = mt9v022_colour_formats; -if (mt9v022->client->dev.platform_data) +if (gpio_is_valid(icl->gpio)) icd->num_formats = ARRAY_SIZE(mt9v022_colour_formats); else icd->num_formats = 1; < at >< at > -733,7 +737,7 < at >< at > static int mt9v022_video_probe(struct soc_camera_device *icd) ret = reg_write(icd, MT9V022_PIXEL_OPERATION_MODE, 0x11); mt9v022->model = V4L2_IDENT_MT9V022IX7ATM; icd->formats = mt9v022_monochrome_formats; -if (mt9v022->client->dev.platform_data) +if (gpio_is_valid(icl->gpio)) icd->num_formats = ARRAY_SIZE(mt9v022_monochrome_formats); else icd->num_formats = 1; diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c index c3e7139..0209462 100644 --- a/drivers/media/video/ov772x.c +++ b/drivers/media/video/ov772x.c < at >< at > -706,12 +706,12 < at >< at > static int ov772x_set_bus_param(struct soc_camera_device *icd, static unsigned long ov772x_query_bus_param(struct soc_camera_device *icd) { struct ov772x_priv *priv = container_of(icd, struct ov772x_priv, icd); - -return SOCAM_PCLK_SAMPLE_RISING | -SOCAM_HSYNC_ACTIVE_HIGH | -SOCAM_VSYNC_ACTIVE_HIGH | -SOCAM_MASTER | +struct soc_camera_link *icl = priv->client->dev.platform_data; +unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER | +SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH | priv->info->buswidth; + +return soc_camera_apply_sensor_flags(icl, flags); } static int ov772x_get_chip_id(struct soc_camera_device *icd, diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h index d1f7241..549d0c2 100644 --- a/include/media/soc_camera.h +++ b/include/media/soc_camera.h < at >< at > -81,11 +81,19 < at >< at > struct soc_camera_host_ops { unsigned int (*poll)(struct file *, poll_table *); }; +#define SOCAM_SENSOR_INVERT_PCLK(1 << 0) +#define SOCAM_SENSOR_INVERT_MCLK(1 << 1) +#define SOCAM_SENSOR_INVERT_HSYNC(1 << 2) +#define SOCAM_SENSOR_INVERT_VSYNC(1 << 3) +#define SOCAM_SENSOR_INVERT_DATA(1 << 4) + struct soc_camera_link { /* Camera bus id, used to match a camera and a bus */ int bus_id; /* GPIO number to switch between 8 and 10 bit modes */ unsigned int gpio; +/* Per camera SOCAM_SENSOR_* bus flags */ +unsigned long flags; /* Optional callbacks to power on or off and reset the sensor */ int (*power)(struct device *, int); int (*reset)(struct device *); < at >< at > -206,4 +214,26 < at >< at > static inline unsigned long soc_camera_bus_param_compatible( return (!hsync || !vsync || !pclk) ? 0 : common_flags; } +/** + * Return flags modified according to SOCAM_SENSOR_* platform configuration + * + * < at >icl:camera platform parameters + * < at >flags:flags to be inverted according to platform configuration + * < at >return:resulting flags + */ +static inline unsigned long soc_camera_apply_sensor_flags(struct soc_camera_link *icl, + unsigned long flags) +{ +if (icl->flags & SOCAM_SENSOR_INVERT_HSYNC) +flags ^= SOCAM_HSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_LOW; + +if (icl->flags & SOCAM_SENSOR_INVERT_VSYNC) +flags ^= SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_VSYNC_ACTIVE_LOW; + +if (icl->flags & SOCAM_SENSOR_INVERT_PCLK) +flags ^= SOCAM_PCLK_SAMPLE_RISING | SOCAM_PCLK_SAMPLE_FALLING; + +return flags; +} + #endif -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list

Re: About CITOR register value for pxa_camera

Guennadi Liakhovetski — 2008-12-01T15:11:38

ic, please, do let us know your results when you upgrade. Yes, please. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list

Re: USB device for uncompressed NTSC capture

Steve Fink — 2008-12-01T18:56:29

Oh, sorry. I was thinking of an external device with analog input and 1394 output. My laptop has a 1394 port. Ah, yes. They do exist: . But (1) I was hoping to pay about a quarter of that, and (2) I still don't understand the Linux side of it -- although it seems like it shouldn't be a problem; I'm assuming I can use a generic 1394 video capture driver, whereas USB would be device-specific. There is a v4l driver for 1394, I hope? -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH] mt9m111: add all yuv format combinations.

Robert Jarzmik — 2008-12-01T18:30:42

Yes, confirmed. I'm using it for some time now, without modification. -- Robert -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng

Hans Verkuil — 2008-12-01T18:07:06

Much appreciated. Using v4l2_i2c_new_subdev or v4l2_i2c_new_probed_subdev should make it much easier to switch over. It certainly simplified it for ivtv. I would like to state again that I have no plans to rename it. There is a chance that it will be used by the dvb subsystem as well in the future, but that's not going to happen any time soon. But should that happen, then we might consider renaming it to media_device/media_subdev. However, right now it is very much v4l2 specific code. I think it more likely that if this is used in dvb then it would be for v4l2 functionality, not dvb functionality. There will definitely be future additions since this is only the first step. Things on my list: better framework support for controls, v4l2_prio handling, adding a similar v4l2_fh struct for filehandle-specific data and the media controller which has been discussed in earlier RFCs and that requires these fundamental data structs to be in place first. Replacing the v4l2-int-device.h API with v4l2_subdev and adding support for sensor drivers to the v4l2_subdev ops will also no doubt require additions. But I want to do this step by step. It's just humanly impossible to go for a Big Bang here. Each time something gets added there must be at least one driver actually using it so you have some confidence in the change. Just integrating these simple v4l2_device and v4l2_subdev structs will take a fair amount of time. Regards, Hans

Re: minimum v4l2 api - framework

Carl Karsten — 2008-12-01T17:30:32

moving this back to the list - seems appropriate This is exactly what I was planning on. I would ask you to add them to the a wiki page about it, but it appears to be missing: http://linuxtv.org/v4lwiki/index.php/Test_Suite As a baseline for what the test app would do when used against a proper driver. I need a driver like what I hoped vivi was: can be run by anyone (it can) and properly implements v4l2 api (questionable. it currently hangs my kernel, so that seems like a problem.) A test driver would 1) help me make sure the test app works correctly. as the test app is modified, the automated test run would first use the test driver to make sure the app is not giving false reports. 2) when the close source driver fails the test app, the developer may want to see an example of what code should look like that doesn't fail. 3) help test v4l apps, like transcode's v4l2_import module. 4) help me develop http://code.google.com/p/python-video4linux2/ That is one of my goals. I also think the v4l community needs such a thing. Otherwise I would not be bothering the community :) to be clear: my relation to this product is a user. my interest in helping the development is because I want it to work for me. Now to answer your question: I think it is the same reason nvidia video drivers are. In this case I think it is to protect the compression algorithm that moves video data over usb2. I am not working with the closed source code. I am just trying to use it, and submit bug reports when it isn't working. Right now I am never sure if the bug is in the closed source driver or the app. having both a reliable test driver and app would help this process. and be a proficient kernel hacker. which I am not. but I have friends that are willing to help if I can give them a reasonable goal. And I hope to create some sort of liveCD (bootable thumb drive really) that would test v4l2 drivers: boot, hardware is identified, modules loaded, tests run, results displayed with an option to send them back to a central database. Carl K -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list

Re: About CITOR register value for pxa_camera

Guennadi Liakhovetski — 2008-12-01T15:14:20

As you might have seen, I posted two patches on the list earlier today (with you on cc), which fix this Oops and one more bug in a formula. If the patches look fine to you or better yet, if you can test them and they pass your test, I'll push them upstream with a next request. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Patches, affecting directories not in hg/linux

Guennadi Liakhovetski — 2008-12-01T15:00:00

Yeah... good question. At first Eric has done everything in one patch: moved defines like -#define CICR0__REG(0x50000000) -#define CICR1__REG(0x50000004) away from arch/arm/mach-pxa/include/mach/pxa-regs.h thus cleaning it up, and replaced them with +#define CICR0(0x0000) +#define CICR1(0x0004) because in the same patch he switch pxa_camera.c from IO-style register access like CICR0 = x; to memmapped IO. So, I asked him to split that patch into two, also to make a clean separation between the ARM and the v4l parts. And this is what he came up with - a header file that is created only to be removed with the next patch. Whereas I hoped he would just first move defines to pxa_camera.c as is, and then replace them _there_ with offsets... But I didn't consider this too bad of a problem to ask him about yet another revision... If you disagree - we can probably still do this. Yep... I'll ask him to let me know when the first patch gets in. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng

Hans Verkuil — 2008-12-01T14:47:27

Agreed. For now it is only relevant for drivers that use subdevices. Am I overlooking something? This API is a kernel API, not a public API. Hence if I (or anyone else for that matter) make future changes then it is my responsibility to adapt all other drivers that are affected at the same time. I don't see how any of this could break compatibility. Except for out-of-kernel drivers, of course. But that's the risk that they always run. Marking this API as experimental seems pointless to me. It either works and so is available for use or it doesn't and then it is a plain old bug that needs to be fixed. I also know already that there will be changes as e.g. sensors require a new ops category and v4l2_device might need a notifier callback as well. However, I'm not going to implement that until there is also a driver that uses it (adding functionality to an internal API just because it might be needed in the future is a really bad idea). Regards, Hans

Re: Patches, affecting directories not in hg/linux

Mauro Carvalho Chehab — 2008-12-01T14:43:13

On Mon, 1 Dec 2008 14:22:17 +0100 (CET) Guennadi Liakhovetski gmx.de> wrote: Argh! Why inserting the header file just to delete on the next patch? For sure we need to wait for the first one to be at -next. Then, we should apply it, with a meta tag "kernel-sync:", to not break the compilation of v4l/dvb tree[1], and apply the second one. [1] The meta-tag will sign to my scripts to discard the patch, not exporting it to -git. Cheers, Mauro -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list

Re: testing soc_camera with mt9m001 on pxa270

Mauro Carvalho Chehab — 2008-12-01T14:37:04

On Mon, 1 Dec 2008 11:43:04 +0100 (CET) Guennadi Liakhovetski gmx.de> wrote: v4l2-ioctl.h doesn't define VIDIOC_REQBUF. It just includes linux/videodev2.h, as: linux/include/linux/videodev2.h:#define VIDIOC_REQBUFS _IOWR('V', 8, struct v4l2_requestbuffers) Can you double check what #define are you using with the driver and with the userspace? Maybe the macro is wrongly evaluated or you're linking against a broken version of the file. There's another possibility: the 3rd argument of the macro is used to determine the size of the parameter. The size of the struct may vary (depending on how the struct is defined), depending on the architecture. In the case of this macro, it is defined as: struct v4l2_requestbuffers { __u32 count; enum v4l2_buf_type type; enum v4l2_memory memory; __u32 reserved[2]; }; On most architectures, enum is evaluated as a 32 bits data. So, the size of the struct is 16. However, on a few architectures, like arm, enum is generally evaluated as 8 bits. You can see some discussions about this at [1]. The fix on ARM is to pass an additional compilation parameter on ARM [2]. Probably, something like this is needed also when compiling v4l utils. [1] http://threebit.net/mail-archive/video4linux/msg01880.html [2] http://threebit.net/mail-archive/video4linux/msg02037.html Cheers, Mauro -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list