Re: [patch][saa7134] do not change mute state for capturing audio
19.07.2011 03:16, Lennart Poettering wrote: ALSA doesn't really have a enumeration API which would allow us to get device properties without opening and configuring a device. In fact, we can't even figure out whether a device may be opened in duplex or simplex without opening it. And that's why we have to probe audio devices, even if it sucks. Hi Lennart, thanks for your opinion. I am puzzled with the even if it sucks part, what does it mean? I see 2 possible interpretations of it: 1. Even if it sucks with some drivers that have bugs, like the saa7134_alsa one. If that interpretation is what you implied, then could you please also evaluate the fix like this one: http://www.spinics.net/lists/linux-media/msg35237.html 2. Even if it sucks in general. In this case, what solution would you propose to get the problem of the white noise fixed? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hauppauge model 73219 rev D1F5 tuner doesn't detect signal, older rev D1E9 works
Hi I have a bunch of Hauppauge HVR-1900 model 73219's, some are revision D1E9 and work perfectly, but with the newer revision D1F5's the tuner fails to detect a signal and consequently just gives me blank output on /dev/video0. Other input sources, like composite or s-video, work just fine on the new revision, it's just the tuner that does not work. I'm 100% certain that there is a live signal since I can use the same source successfully with a D1E9 and then move it to a D1F5 and see it fail. I've also tried both with a real TV signal and with a signal generator (so I could be 100% certain what signal was generated and at what frequency etc). I'm also fairly certain that it's not just a case of a random broken D1F5 since I have several and they all behave identically (and the driver doesn't complain about broken hardware). Here's what I get in dmesg when plugging one of the newer, non-working, devices into my laptop (running 2.6.39.3 by the way): [43171.480193] pvrusb2: Device being rendered inoperable [43173.195741] usb 1-1.1: new high speed USB device number 21 using ehci_hcd [43173.28] pvrusb2: Hardware description: WinTV HVR-1900 Model 73xxx [43173.321796] pvrusb2: Binding ir_rx_z8f0811_haup to i2c address 0x71. [43173.321817] pvrusb2: Binding ir_tx_z8f0811_haup to i2c address 0x70. [43173.325212] cx25840 18-0044: cx25843-24 found @ 0x88 (pvrusb2_a) [43173.335618] pvrusb2: Attached sub-driver cx25840 [43173.339439] tuner 18-0042: Tuner -1 found with type(s) Radio TV. [43173.339448] pvrusb2: Attached sub-driver tuner [43175.538224] cx25840 18-0044: loaded v4l-cx25840.fw firmware (16382 bytes) [43175.641103] tveeprom 18-00a2: Hauppauge model 73219, rev D1F5, serial# 6569758 [43175.641109] tveeprom 18-00a2: MAC address is 00:0d:fe:64:3f:1e [43175.641114] tveeprom 18-00a2: tuner model is NXP 18271C2 (idx 155, type 54) [43175.641119] tveeprom 18-00a2: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xf4) [43175.641124] tveeprom 18-00a2: audio processor is CX25843 (idx 37) [43175.641128] tveeprom 18-00a2: decoder processor is CX25843 (idx 30) [43175.641132] tveeprom 18-00a2: has radio, has IR receiver, has IR transmitter [43175.641142] pvrusb2: Supported video standard(s) reported available in hardware: PAL-B/B1/D/D1/G/H/I/K;SECAM-B/D/G/H/K/K [43175.641152] pvrusb2: Mapping standards mask=0x3ff00ff (PAL-B/B1/D/D1/G/H/I/K;SECAM-B/D/G/H/K/K1/L/LC;ATSC-8VSB/16VSB) [43175.641156] pvrusb2: Setting up 20 unique standard(s) [43175.641161] pvrusb2: Set up standard idx=0 name=PAL-B/G [43175.641165] pvrusb2: Set up standard idx=1 name=PAL-D/K [43175.641169] pvrusb2: Set up standard idx=2 name=SECAM-B/G [43175.641172] pvrusb2: Set up standard idx=3 name=SECAM-D/K [43175.641176] pvrusb2: Set up standard idx=4 name=PAL-B [43175.641179] pvrusb2: Set up standard idx=5 name=PAL-B1 [43175.641182] pvrusb2: Set up standard idx=6 name=PAL-G [43175.641185] pvrusb2: Set up standard idx=7 name=PAL-H [43175.641189] pvrusb2: Set up standard idx=8 name=PAL-I [43175.641192] pvrusb2: Set up standard idx=9 name=PAL-D [43175.641195] pvrusb2: Set up standard idx=10 name=PAL-D1 [43175.641198] pvrusb2: Set up standard idx=11 name=PAL-K [43175.641202] pvrusb2: Set up standard idx=12 name=SECAM-B [43175.641205] pvrusb2: Set up standard idx=13 name=SECAM-D [43175.641208] pvrusb2: Set up standard idx=14 name=SECAM-G [43175.641212] pvrusb2: Set up standard idx=15 name=SECAM-H [43175.641215] pvrusb2: Set up standard idx=16 name=SECAM-K [43175.641218] pvrusb2: Set up standard idx=17 name=SECAM-K1 [43175.641221] pvrusb2: Set up standard idx=18 name=SECAM-L [43175.641225] pvrusb2: Set up standard idx=19 name=SECAM-LC [43175.641228] pvrusb2: Initial video standard auto-selected to PAL-B/G [43175.641240] pvrusb2: Device initialization completed successfully. [43175.641361] pvrusb2: registered device video1 [mpeg] [43175.641365] DVB: registering new adapter (pvrusb2-dvb) [43177.891568] cx25840 18-0044: loaded v4l-cx25840.fw firmware (16382 bytes) [43178.010913] tda829x 18-0042: setting tuner address to 60 [43178.034089] tda18271 18-0060: creating new instance [43178.070613] TDA18271HD/C2 detected @ 18-0060 [43179.945888] tda18271: performing RF tracking filter calibration [43192.930384] tda18271: RF tracking filter calibration complete [43192.973646] tda829x 18-0042: type set to tda8295+18271 [43196.561274] cx25840 18-0044: 0x is not a valid video input! [43196.593146] DVB: registering adapter 0 frontend 0 (NXP TDA10048HN DVB-T)... [43196.594644] tda829x 18-0042: type set to tda8295 [43196.630097] tda18271 18-0060: attaching existing instance [43205.439659] cx25840 18-0044: loaded v4l-cx25840.fw firmware (16382 bytes) The only differences between this output and a working device is the revision number and the fact that the tuner is a TDA18271HD/C2 whereas with the older (working) devices it's a TDA18271HD/C1. Here's what I do to test problem: [root@dragon ~]# echo television
Re: [PATCH] add support for the dvb-t part of CT-3650 v3
On Martes, 19 de Julio de 2011 01:44:54 Antti Palosaari escribió: On 07/19/2011 02:00 AM, Jose Alberto Reguero wrote: On Lunes, 18 de Julio de 2011 22:28:41 Antti Palosaari escribió: Hello I did some review for this since I was interested of adding MFE for Anysee driver which is rather similar (dvb-usb-framework). I found this patch have rather major issue(s) which should be fixed properly. * it does not compile drivers/media/dvb/dvb-usb/dvb-usb.h:24:21: fatal error: dvb-pll.h: No such file or directory Perhaps you need to add: -Idrivers/media/dvb/frontends/ in: drivers/media/dvb/frontends/Makefile I compile the driver with: git://linuxtv.org/mchehab/new_build.git and I not have this problem. Maybe, I was running latest Git. Not big issue. * it puts USB-bridge functionality to the frontend driver * 1st FE, TDA10023, is passed as pointer inside config to 2nd FE TDA10048. Much of glue sleep, i2c etc, those calls are wrapped back to to 1st FE... * no exclusive locking between MFEs. What happens if both are accessed same time? Almost all those are somehow chained to same issue, few calls to 2nd FE are wrapped to 1st FE. Maybe IOCTL override callback could help if those are really needed. There are two problems: First, the two frontends (tda10048 and tda10023) use tda10023 i2c gate to talk with the tuner. Very easy to implement correctly. Attach tda10023 first and after that tda10048. Override tda10048 .i2c_gate_ctrl() with tda10023 .i2c_gate_ctrl() immediately after tda10048 attach inside ttusb2.c. Now you have both demods (FEs) .i2c_gate_ctrl() which will control physically tda10023 I2C-gate as tuner is behind it. I try that, but don't work. I get an oops. Because the i2c gate function of the tda10023 driver use: struct tda10023_state* state = fe-demodulator_priv; to get the i2c adress. When called from tda10048, don't work. Jose Alberto The second is that with dvb-usb, there is only one frontend, and if you wake up the second frontend, the adapter is not wake up. That can be avoided the way I do in the patch, or mantaining the adapter alwais on. I think that could be also avoided similarly overriding demod callbacks and adding some more logic inside ttusb2.c. Proper fix that later problem is surely correct MFE support for DVB-USB-framework. I am now looking for it, lets see how difficult it will be. regards Antti -- 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 for Asus My Cinema PS3-100 (1043:48cd)
Le vendredi 15 juillet 2011, remzouille a écrit :
Le jeudi 14 juillet 2011 18:50:39, vous avez écrit :
Em 14-07-2011 06:28, remzouille escreveu:
Hi all,
This is the patch against kernel 2.6.32 I used to get to work my TV
card Asus My Cinema PS3-100 (1043:48cd).
More information on this card can be found on this page :
http://techblog.hollants.com/2009/09/asus-mycinema-ps3-100-3-in-1-tv-ca
rd /
This card seems to be a clone of the Asus Tiger 3in1, numbered 147 in
the SAA7134 module, so I gave it the temporary number of 1470.
It has in addition a remote controller that works fine with the
ir_codes_asus_pc39_table. I haven't finished the work on all keys but
the most usefull ones are working.
Please finish the keytable mapping and re-send it with your
Signed-off-By.
Ok, I'll do that when I am back at home in a few days.
As I said, the remote is already quite fully functional.
The remote part is now complete.
DVB-T and remote have been tested and work fine.
DVB-S, FM and Composite input haven't been tested.
Hope that will help some of you.
Thanks!
Mauro
You're welcome !
Rémi
Signed-off-by: Remzouille remzoui...@free.fr
--- ./include/media/ir-common.h.orig 2009-12-03 04:51:21.0 +0100
+++ ./include/media/ir-common.h 2011-07-18 23:53:17.281797898 +0200
@@ -155,6 +155,7 @@ extern struct ir_scancode_table ir_codes
extern struct ir_scancode_table ir_codes_proteus_2309_table;
extern struct ir_scancode_table ir_codes_budget_ci_old_table;
extern struct ir_scancode_table ir_codes_asus_pc39_table;
+extern struct ir_scancode_table ir_codes_asus_ps3_100_table;
extern struct ir_scancode_table ir_codes_encore_enltv_table;
extern struct ir_scancode_table ir_codes_encore_enltv2_table;
extern struct ir_scancode_table ir_codes_tt_1500_table;
--- ./drivers/media/common/ir-keymaps.c.orig 2009-12-03 04:51:21.0 +0100
+++ ./drivers/media/common/ir-keymaps.c 2011-07-19 00:10:56.090801168 +0200
@@ -2064,6 +2064,70 @@ struct ir_scancode_table ir_codes_asus_p
EXPORT_SYMBOL_GPL(ir_codes_asus_pc39_table);
+/*
+ * Remzouille remzoui...@free.fr
+ * this is the remote control that comes with the asus my cinema ps3-100
+ * base taken from pc39 one
+ */
+static struct ir_scancode ir_codes_asus_ps3_100[] = {
+ { 0x23, KEY_HOME }, /* home */
+ { 0x21, KEY_TV }, /* tv */
+ { 0x3c, KEY_TEXT }, /* teletext */
+ { 0x16, KEY_POWER }, /* close */
+
+ { 0x34, KEY_RED }, /* red */
+ { 0x32, KEY_YELLOW }, /* yellow */
+ { 0x39, KEY_BLUE }, /* blue */
+ { 0x38, KEY_GREEN }, /* green */
+
+ /* Keys 0 to 9 */
+ { 0x15, KEY_0 },
+ { 0x29, KEY_1 },
+ { 0x2d, KEY_2 },
+ { 0x2b, KEY_3 },
+ { 0x09, KEY_4 },
+ { 0x0d, KEY_5 },
+ { 0x0b, KEY_6 },
+ { 0x31, KEY_7 },
+ { 0x35, KEY_8 },
+ { 0x33, KEY_9 },
+
+ { 0x2a, KEY_VOLUMEUP },
+ { 0x19, KEY_VOLUMEDOWN },
+ { 0x0a, KEY_CHANNELUP }, /* channel / program + */
+ { 0x1b, KEY_CHANNELDOWN }, /* channel / program - */
+
+ { 0x37, KEY_UP },
+ { 0x3b, KEY_DOWN },
+ { 0x27, KEY_LEFT },
+ { 0x2f, KEY_RIGHT },
+ { 0x1a, KEY_ENTER }, /* enter */
+
+ { 0x1d, KEY_EXIT }, /* back */
+ { 0x13, KEY_AB }, /* recall */
+
+ { 0x1f, KEY_AUDIO }, /* TV audio */
+ { 0x08, KEY_SCREEN }, /* snapshot */
+ { 0x11, KEY_ZOOM }, /* full screen */
+ { 0x3d, KEY_MUTE }, /* mute */
+
+ { 0x0e, KEY_REWIND }, /* backward */
+ { 0x2e, KEY_RECORD }, /* recording */
+ { 0x36, KEY_STOP },
+ { 0x3a, KEY_FASTFORWARD }, /* forward */
+ { 0x1e, KEY_PREVIOUS }, /* rew */
+ { 0x25, KEY_PAUSE }, /* pause */
+ { 0x06, KEY_PLAY }, /* play */
+ { 0x26, KEY_NEXT }, /* forward */
+};
+
+struct ir_scancode_table ir_codes_asus_ps3_100_table = {
+ .scan = ir_codes_asus_ps3_100,
+ .size = ARRAY_SIZE(ir_codes_asus_ps3_100),
+};
+EXPORT_SYMBOL_GPL(ir_codes_asus_ps3_100_table);
+
+
/* Encore ENLTV-FM - black plastic, white front cover with white glowing buttons
Juan Pablo Sormani sor...@gmail.com */
static struct ir_scancode ir_codes_encore_enltv[] = {
--- ./drivers/media/video/saa7134/saa7134-input.c.orig 2009-12-03 04:51:21.0 +0100
+++ ./drivers/media/video/saa7134/saa7134-input.c 2011-07-18 23:53:17.293797824 +0200
@@ -575,6 +575,11 @@ int saa7134_input_init1(struct saa7134_d
mask_keydown = 0x004;
rc5_gpio = 1;
break;
+ case SAA7134_BOARD_ASUSTeK_PS3_100:
+ ir_codes = ir_codes_asus_ps3_100_table;
+ mask_keydown = 0x004;
+ rc5_gpio = 1;
+ break;
case SAA7134_BOARD_ENCORE_ENLTV:
case SAA7134_BOARD_ENCORE_ENLTV_FM:
ir_codes = ir_codes_encore_enltv_table;
--- ./drivers/media/video/saa7134/saa7134-dvb.c.orig 2011-06-11 21:08:41.0 +0200
+++ ./drivers/media/video/saa7134/saa7134-dvb.c 2011-07-18 23:53:17.293797824 +0200
@@ -824,6 +824,20 @@ static struct tda1004x_config asus_tiger
.request_firmware = philips_tda1004x_request_firmware
};
+static struct tda1004x_config asus_ps3_100_config = {
+ .demod_address = 0x0b,
+ .invert= 1,
+ .invert_oclk = 0,
+
Re: patch for Asus My Cinema PS3-100 (1043:48cd)
Le vendredi 15 juillet 2011, remzouille a écrit :
Le jeudi 14 juillet 2011 18:50:39, vous avez écrit :
Em 14-07-2011 06:28, remzouille escreveu:
Hi all,
This is the patch against kernel 2.6.32 I used to get to work my TV
card Asus My Cinema PS3-100 (1043:48cd).
More information on this card can be found on this page :
http://techblog.hollants.com/2009/09/asus-mycinema-ps3-100-3-in-1-tv-ca
rd /
This card seems to be a clone of the Asus Tiger 3in1, numbered 147 in
the SAA7134 module, so I gave it the temporary number of 1470.
It has in addition a remote controller that works fine with the
ir_codes_asus_pc39_table. I haven't finished the work on all keys but
the most usefull ones are working.
Please finish the keytable mapping and re-send it with your
Signed-off-By.
Ok, I'll do that when I am back at home in a few days.
As I said, the remote is already quite fully functional.
The remote part is now complete.
DVB-T and remote have been tested and work fine.
DVB-S, FM and Composite input haven't been tested.
Hope that will help some of you.
Thanks!
Mauro
You're welcome !
Rémi
Signed-off-by: Remzouille remzoui...@free.fr
--- ./include/media/ir-common.h.orig 2009-12-03 04:51:21.0 +0100
+++ ./include/media/ir-common.h 2011-07-18 23:53:17.281797898 +0200
@@ -155,6 +155,7 @@ extern struct ir_scancode_table ir_codes
extern struct ir_scancode_table ir_codes_proteus_2309_table;
extern struct ir_scancode_table ir_codes_budget_ci_old_table;
extern struct ir_scancode_table ir_codes_asus_pc39_table;
+extern struct ir_scancode_table ir_codes_asus_ps3_100_table;
extern struct ir_scancode_table ir_codes_encore_enltv_table;
extern struct ir_scancode_table ir_codes_encore_enltv2_table;
extern struct ir_scancode_table ir_codes_tt_1500_table;
--- ./drivers/media/common/ir-keymaps.c.orig 2009-12-03 04:51:21.0 +0100
+++ ./drivers/media/common/ir-keymaps.c 2011-07-19 00:10:56.090801168 +0200
@@ -2064,6 +2064,70 @@ struct ir_scancode_table ir_codes_asus_p
EXPORT_SYMBOL_GPL(ir_codes_asus_pc39_table);
+/*
+ * Remzouille remzoui...@free.fr
+ * this is the remote control that comes with the asus my cinema ps3-100
+ * base taken from pc39 one
+ */
+static struct ir_scancode ir_codes_asus_ps3_100[] = {
+ { 0x23, KEY_HOME }, /* home */
+ { 0x21, KEY_TV }, /* tv */
+ { 0x3c, KEY_TEXT }, /* teletext */
+ { 0x16, KEY_POWER }, /* close */
+
+ { 0x34, KEY_RED }, /* red */
+ { 0x32, KEY_YELLOW }, /* yellow */
+ { 0x39, KEY_BLUE }, /* blue */
+ { 0x38, KEY_GREEN }, /* green */
+
+ /* Keys 0 to 9 */
+ { 0x15, KEY_0 },
+ { 0x29, KEY_1 },
+ { 0x2d, KEY_2 },
+ { 0x2b, KEY_3 },
+ { 0x09, KEY_4 },
+ { 0x0d, KEY_5 },
+ { 0x0b, KEY_6 },
+ { 0x31, KEY_7 },
+ { 0x35, KEY_8 },
+ { 0x33, KEY_9 },
+
+ { 0x2a, KEY_VOLUMEUP },
+ { 0x19, KEY_VOLUMEDOWN },
+ { 0x0a, KEY_CHANNELUP }, /* channel / program + */
+ { 0x1b, KEY_CHANNELDOWN }, /* channel / program - */
+
+ { 0x37, KEY_UP },
+ { 0x3b, KEY_DOWN },
+ { 0x27, KEY_LEFT },
+ { 0x2f, KEY_RIGHT },
+ { 0x1a, KEY_ENTER }, /* enter */
+
+ { 0x1d, KEY_EXIT }, /* back */
+ { 0x13, KEY_AB }, /* recall */
+
+ { 0x1f, KEY_AUDIO }, /* TV audio */
+ { 0x08, KEY_SCREEN }, /* snapshot */
+ { 0x11, KEY_ZOOM }, /* full screen */
+ { 0x3d, KEY_MUTE }, /* mute */
+
+ { 0x0e, KEY_REWIND }, /* backward */
+ { 0x2e, KEY_RECORD }, /* recording */
+ { 0x36, KEY_STOP },
+ { 0x3a, KEY_FASTFORWARD }, /* forward */
+ { 0x1e, KEY_PREVIOUS }, /* rew */
+ { 0x25, KEY_PAUSE }, /* pause */
+ { 0x06, KEY_PLAY }, /* play */
+ { 0x26, KEY_NEXT }, /* forward */
+};
+
+struct ir_scancode_table ir_codes_asus_ps3_100_table = {
+ .scan = ir_codes_asus_ps3_100,
+ .size = ARRAY_SIZE(ir_codes_asus_ps3_100),
+};
+EXPORT_SYMBOL_GPL(ir_codes_asus_ps3_100_table);
+
+
/* Encore ENLTV-FM - black plastic, white front cover with white glowing buttons
Juan Pablo Sormani sor...@gmail.com */
static struct ir_scancode ir_codes_encore_enltv[] = {
--- ./drivers/media/video/saa7134/saa7134-input.c.orig 2009-12-03 04:51:21.0 +0100
+++ ./drivers/media/video/saa7134/saa7134-input.c 2011-07-18 23:53:17.293797824 +0200
@@ -575,6 +575,11 @@ int saa7134_input_init1(struct saa7134_d
mask_keydown = 0x004;
rc5_gpio = 1;
break;
+ case SAA7134_BOARD_ASUSTeK_PS3_100:
+ ir_codes = ir_codes_asus_ps3_100_table;
+ mask_keydown = 0x004;
+ rc5_gpio = 1;
+ break;
case SAA7134_BOARD_ENCORE_ENLTV:
case SAA7134_BOARD_ENCORE_ENLTV_FM:
ir_codes = ir_codes_encore_enltv_table;
--- ./drivers/media/video/saa7134/saa7134-dvb.c.orig 2011-06-11 21:08:41.0 +0200
+++ ./drivers/media/video/saa7134/saa7134-dvb.c 2011-07-18 23:53:17.293797824 +0200
@@ -824,6 +824,20 @@ static struct tda1004x_config asus_tiger
.request_firmware = philips_tda1004x_request_firmware
};
+static struct tda1004x_config asus_ps3_100_config = {
+ .demod_address = 0x0b,
+ .invert= 1,
+ .invert_oclk = 0,
+
[GIT PATCHES FOR 3.1] pwc: Add support for control events
Hi Mauro, Please pull from my tree to add support for control events to the pwc driver. Note that this patch depends upon the patches from hverkuils poll tree (and those patches are thus also in my tree, but not part of this pull req). The following changes since commit 30178e8623281063c18592a848cdcd71f78f603d: vivi: let vb2_poll handle events. (2011-07-18 13:07:28 +0200) are available in the git repository at: git://linuxtv.org/hgoede/gspca.git media-for_v3.1 Hans de Goede (1): pwc: Add support for control events drivers/media/video/pwc/pwc-if.c | 84 - drivers/media/video/pwc/pwc-v4l.c | 16 ++- drivers/media/video/pwc/pwc.h |4 ++ 3 files changed, 53 insertions(+), 51 deletions(-) Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 3.1] pwc: Add support for control events
Hi, On 07/19/2011 12:33 PM, Hans de Goede wrote: Hi Mauro, Please pull from my tree to add support for control events to the pwc driver. Note that this patch depends upon the patches from hverkuils poll tree (and those patches are thus also in my tree, but not part of this pull req). The following changes since commit 30178e8623281063c18592a848cdcd71f78f603d: vivi: let vb2_poll handle events. (2011-07-18 13:07:28 +0200) are available in the git repository at: git://linuxtv.org/hgoede/gspca.git media-for_v3.1 Hans de Goede (1): pwc: Add support for control events Self NACK, I just noticed that I got the release / unregister handling wrong. Will re do and re-submit a pull req later. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 1/8] davinci: vpfe: add dm3xx IPIPEIF hardware support module
Sakari,
Thank you for your comments. I agree with them and fix. Please comment on the
rest of the patches as well.
-Manju
On Thu, Jul 14, 2011 at 00:20:50, Sakari Ailus wrote:
Hi Manju,
Thanks for the patchset!
I have a few comments on this patch below. I haven't read the rest of the
patches yet so I may have more comments on this one when I do that.
On Thu, Jun 30, 2011 at 06:43:10PM +0530, Manjunath Hadli wrote:
add support for dm3xx IPIPEIF hardware setup. This is the lowest
software layer for the dm3x vpfe driver which directly accesses
hardware. Add support for features like default pixel correction, dark
frame substraction and hardware setup.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Nagabhushana Netagunte nagabhushana.netagu...@ti.com
---
drivers/media/video/davinci/dm3xx_ipipeif.c | 368
+++
include/media/davinci/dm3xx_ipipeif.h | 292 +
2 files changed, 660 insertions(+), 0 deletions(-) create mode
100644 drivers/media/video/davinci/dm3xx_ipipeif.c
create mode 100644 include/media/davinci/dm3xx_ipipeif.h
diff --git a/drivers/media/video/davinci/dm3xx_ipipeif.c
b/drivers/media/video/davinci/dm3xx_ipipeif.c
new file mode 100644
index 000..36cb61b
--- /dev/null
+++ b/drivers/media/video/davinci/dm3xx_ipipeif.c
@@ -0,0 +1,368 @@
+/*
+* Copyright (C) 2011 Texas Instruments Inc
+*
+* This program is free software; you can redistribute it and/or
+* modify it under the terms of the GNU General Public License as
+* published by the Free Software Foundation version 2.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+* GNU General Public License for more details.
+*
+* You should have received a copy of the GNU General Public License
+* along with this program; if not, write to the Free Software
+* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+02111-1307 USA
+*
+* ipipe module to hold common functionality across DM355 and DM365 */
+#include linux/kernel.h #include linux/platform_device.h #include
+linux/uaccess.h #include linux/io.h #include
+linux/v4l2-mediabus.h #include media/davinci/dm3xx_ipipeif.h
+
+#define DM355 0
+#define DM365 1
+
+static void *__iomem ipipeif_base_addr;
This looks device specific. What about using dev_set/get_drvdata and remove
this one?
+static int device_type;
Ditto. Both should be in a device specific struct.
I will move both of the above to platform file.
+static inline u32 regr_if(u32 offset) {
+ return readl(ipipeif_base_addr + offset); }
+
+static inline void regw_if(u32 val, u32 offset) {
+ writel(val, ipipeif_base_addr + offset); }
+
+void ipipeif_set_enable(char en, unsigned int mode) {
+ regw_if(1, IPIPEIF_ENABLE);
+}
+
+u32 ipipeif_get_enable(void)
+{
+ return regr_if(IPIPEIF_ENABLE);
+}
+
+int ipipeif_set_address(struct ipipeif *params, unsigned int address)
+{
If address is a value for a register you should use u32.
Okay.
+ unsigned int val1;
+ unsigned int val;
+
+ if (params-source != 0) {
+ val = ((params-adofs 5) IPIPEIF_ADOFS_LSB_MASK);
+ regw_if(val, IPIPEIF_ADOFS);
You may do without val as well.
+ /* lower sixteen bit */
+ val = ((address IPIPEIF_ADDRL_SHIFT) IPIPEIF_ADDRL_MASK);
+ regw_if(val, IPIPEIF_ADDRL);
+
+ /* upper next seven bit */
+ val1 =
+ ((address IPIPEIF_ADDRU_SHIFT) IPIPEIF_ADDRU_MASK);
+ regw_if(val1, IPIPEIF_ADDRU);
+ } else
+ return -1;
What's -1? If this is an error, Ex codes should be used.
The error check should become first and the rest of the function may be
unindented by one tab stop.
Okay.
+ return 0;
+}
+
+static void ipipeif_config_dpc(struct ipipeif_dpc *dpc) {
+ u32 val;
+
+ if (dpc-en) {
+ val = ((dpc-en 1) IPIPEIF_DPC2_EN_SHIFT);
+ val |= (dpc-thr IPIPEIF_DPC2_THR_MASK);
+ } else
+ val = 0;
+
+ regw_if(val, IPIPEIF_DPC2);
+}
+
+/* This function sets up IPIPEIF and is called from
+ * ipipe_hw_setup()
+ */
+int ipipeif_hw_setup(struct ipipeif *params) {
+ enum v4l2_mbus_pixelcode isif_port_if;
+ unsigned int val1 = 0x7;
7 looks like a magic number.
Will fix.
+ unsigned int val;
+
+ if (NULL == params)
+ return -1;
Same here, and I can also see elsewhere.
Will fix.
+ /* Enable clock to IPIPEIF and IPIPE */
+ if (device_type == DM365)
+ vpss_enable_clock(VPSS_IPIPEIF_CLOCK, 1);
+
+ /* Combine all the fields to make CFG1 register of IPIPEIF */
+ val = params-mode ONESHOT_SHIFT;
+ val |= params-source
Re: FW: [PATCH] drivers: support new Siano tuner devices.
Adding linux-media@vger.kernel.org to CC
On Tue, 19 Jul 2011, Doron Cohen wrote:
Hi,
This is the first time I ever post changes to linux kernel, so excuse me
if I have errors in the process.
As Siano team member, I would like to update the drivers for Siano
devices with the latest and greatest fixes. Unfortunately there is a hug
gap between the current code in the kernel and the code Siano has which
is more advanced and supports newer devices. I will try to break down
the changes into small pieces so each of the changes will be clear and
isolated.
Here is the first change which is my test balloon and includes simple
changes which includes support in new devices pulished after the kernel
source maintenance has stopped.
diff --git a/drivers/media/dvb/siano/sms-cards.c
b/drivers/media/dvb/siano/sms-cards.c
index af121db..302a9e3 100644
--- a/drivers/media/dvb/siano/sms-cards.c
+++ b/drivers/media/dvb/siano/sms-cards.c
@@ -26,45 +26,66 @@ MODULE_PARM_DESC(cards_dbg, set debug level
(info=1, adv=2 (or-able)));
static struct sms_board sms_boards[] = {
[SMS_BOARD_UNKNOWN] = {
- .name = Unknown board,
+ /* 0 */
+ .name = Unknown board,
+ .type = SMS_UNKNOWN_TYPE,
+ .default_mode = DEVICE_MODE_NONE,
},
[SMS1XXX_BOARD_SIANO_STELLAR] = {
- .name = Siano Stellar Digital Receiver,
- .type = SMS_STELLAR,
+ /* 1 */
+ .name =
+ Siano Stellar Digital Receiver,
+ .type = SMS_STELLAR,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
},
[SMS1XXX_BOARD_SIANO_NOVA_A] = {
- .name = Siano Nova A Digital Receiver,
- .type = SMS_NOVA_A0,
+ /* 2 */
+ .name = Siano Nova A Digital Receiver,
+ .type = SMS_NOVA_A0,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
},
[SMS1XXX_BOARD_SIANO_NOVA_B] = {
- .name = Siano Nova B Digital Receiver,
- .type = SMS_NOVA_B0,
+ /* 3 */
+ .name = Siano Nova B Digital Receiver,
+ .type = SMS_NOVA_B0,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
},
[SMS1XXX_BOARD_SIANO_VEGA] = {
- .name = Siano Vega Digital Receiver,
- .type = SMS_VEGA,
+ /* 4 */
+ .name = Siano Vega Digital Receiver,
+ .type = SMS_VEGA,
+ .default_mode = DEVICE_MODE_CMMB,
},
[SMS1XXX_BOARD_HAUPPAUGE_CATAMOUNT] = {
- .name = Hauppauge Catamount,
- .type = SMS_STELLAR,
- .fw[DEVICE_MODE_DVBT_BDA] =
sms1xxx-stellar-dvbt-01.fw,
+ /* 5 */
+ .name = Hauppauge Catamount,
+ .type = SMS_STELLAR,
+ .fw[DEVICE_MODE_DVBT_BDA] =
+ sms1xxx-stellar-dvbt-01.fw,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
},
[SMS1XXX_BOARD_HAUPPAUGE_OKEMO_A] = {
- .name = Hauppauge Okemo-A,
- .type = SMS_NOVA_A0,
- .fw[DEVICE_MODE_DVBT_BDA] = sms1xxx-nova-a-dvbt-01.fw,
+ /* 6 */
+ .name = Hauppauge Okemo-A,
+ .type = SMS_NOVA_A0,
+ .fw[DEVICE_MODE_DVBT_BDA] =
+ sms1xxx-nova-a-dvbt-01.fw,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
},
[SMS1XXX_BOARD_HAUPPAUGE_OKEMO_B] = {
- .name = Hauppauge Okemo-B,
- .type = SMS_NOVA_B0,
- .fw[DEVICE_MODE_DVBT_BDA] = sms1xxx-nova-b-dvbt-01.fw,
+ /* 7 */
+ .name = Hauppauge Okemo-B,
+ .type = SMS_NOVA_B0,
+ .fw[DEVICE_MODE_DVBT_BDA] =
+ sms1xxx-nova-b-dvbt-01.fw,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
},
[SMS1XXX_BOARD_HAUPPAUGE_WINDHAM] = {
- .name = Hauppauge WinTV MiniStick,
- .type = SMS_NOVA_B0,
- .fw[DEVICE_MODE_ISDBT_BDA] =
sms1xxx-hcw-55xxx-isdbt-02.fw,
+ /* 8 */
+ .name = Hauppauge WinTV MiniStick,
+ .type = SMS_NOVA_B0,
.fw[DEVICE_MODE_DVBT_BDA] =
sms1xxx-hcw-55xxx-dvbt-02.fw,
- .rc_codes = RC_MAP_HAUPPAUGE,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
.board_cfg.leds_power = 26,
.board_cfg.led0 = 27,
.board_cfg.led1 = 28,
@@ -74,30 +95,92 @@ static struct sms_board sms_boards[] = {
.led_hi= 28,
},
[SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD] = {
+ /* 9 */
.name = Hauppauge WinTV MiniCard,
.type = SMS_NOVA_B0,
.fw[DEVICE_MODE_DVBT_BDA] =
sms1xxx-hcw-55xxx-dvbt-02.fw,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
.lna_ctrl = 29,
.board_cfg.foreign_lna0_ctrl = 29,
.rf_switch = 17,
.board_cfg.rf_switch_uhf = 17,
[GIT PATCHES FOR 3.1] pwc: Add support for control events (v2)
Hi Mauro, Please pull from my tree to add support for control events to the pwc driver. Note that this patch depends upon the patches from hverkuils poll tree (and those patches are thus also in my tree, but not part of this pull req). The following changes since commit 30178e8623281063c18592a848cdcd71f78f603d: vivi: let vb2_poll handle events. (2011-07-18 13:07:28 +0200) are available in the git repository at: git://linuxtv.org/hgoede/gspca.git media-for_v3.1 Hans de Goede (2): pwc: Add support for control events pwc: properly mark device_hint as unused in all probe error paths drivers/media/video/pwc/pwc-if.c | 79 ++-- drivers/media/video/pwc/pwc-v4l.c | 16 ++- drivers/media/video/pwc/pwc.h |4 ++ 3 files changed, 48 insertions(+), 51 deletions(-) Regards, Hans -- 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: removing a bunch of module options from the pwc driver
Hi, In the light of my ongoing pwc driver cleanup I would like to remove a bunch of module options, like the device_hint option which allows one the specify a preferred minor, which does not really fit well in our modern dynamic minor v4l2 config, and there are a bunch of options for things which should set through the v4l2 API rather then through a module option, like fps. I thought I would consult the list before ripping this out, in case someone considers removing module options ABI breakage... So any objections? Regards, Hans -- 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: removing pwc kconfig options
Hi, The pwc driver currently has 2 kconfig options, one to enable / disable various debugging options, and another for enabling/ disabling input-evdev support. IMHO these both can go away, the debugging can trigger on CONFIG_VIDEO_ADV_DEBUG, and the input on CONFIG_INPUT. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] imon: don't submit urb before rc_dev set up
On Jul 18, 2011, at 6:29 PM, Chris W l...@psychogeeks.com wrote: On 19/07/11 02:46, Jarod Wilson wrote: The interface 0 urb callback was being wired up before the rc_dev device was allocated, meaning the callback could be called with a null rc_dev, leading to an oops. This likely only ever happens on the older 0xffdc SoundGraph devices, which continually trigger interrupts even when they have no valid keydata, and the window in which it could happen is small, but its actually happening regularly for at least one user, and its an obvious fix. Compile and sanity-tested with one of my own imon devices. As the at least one user I can confirm that the patch has indeed corrected the problem on my 2.6.38-gentoo-r6, 2.6.39.3 vanilla, and 3.0.0-rc7 kernels. This is what loading the module with the debug=1 option outputs: input: iMON Panel, Knob and Mouse(15c2:ffdc) as /devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/input/input7 imon 4-2:1.0: Unknown 0xffdc device, defaulting to VFD and iMON IR (id 0x00) Ugh, damn, that change broke the ffdc device auto-detection... Better than a crash, but lemme see if I can alter things slightly so we can have our cake and eat it too... Registered IR keymap rc-imon-pad input: iMON Remote (15c2:ffdc) as /devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/rc/rc2/input8 rc2: iMON Remote (15c2:ffdc) as /devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/rc/rc2 imon 4-2:1.0: iMON device (15c2:ffdc, intf0) on usb4:3 initialized usbcore: registered new interface driver imon intf0 decoded packet: 00 00 00 00 00 00 24 01 intf0 decoded packet: 00 00 00 00 00 00 24 01 intf0 decoded packet: 00 00 00 00 00 00 24 01 intf0 decoded packet: 00 00 00 00 00 00 24 01 ... The decoded packet lines are fast and furious with no deliberate IR input (the VFD is in use), which might explain how this device managed to break the code in the small window available. Yep. I hate hate hate hate the ffdc imon hardware, for this and multiple other reasons (including the nasty hack used for ffdc device type auto-detection)... My ffdc devices do similar constant spewing, but never triggered the oops, so maybe yours is even worse, or your system is faster, or a kernel config change made a difference here... Thank you Jarod and Andy for taking the time to track this problem down to give it a drubbing. Thanks for the testing and patience, hopefully just one more patch to test out before we can say case closed here... --jarod -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drivers: support new Siano tuner devices.
Hi,
This is the first time I ever post changes to linux kernel, so excuse me
if I have errors in the process.
As Siano team member, I would like to update the drivers for Siano
devices with the latest and greatest fixes. Unfortunately there is a hug
gap between the current code in the kernel and the code Siano has which
is more advanced and supports newer devices. I will try to break down
the changes into small pieces so each of the changes will be clear and
isolated.
Here is the first change which is my test balloon and includes simple
changes which includes support in new devices pulished after the kernel
source maintenance has stopped.
diff --git a/drivers/media/dvb/siano/sms-cards.c
b/drivers/media/dvb/siano/sms-cards.c
index af121db..302a9e3 100644
--- a/drivers/media/dvb/siano/sms-cards.c
+++ b/drivers/media/dvb/siano/sms-cards.c
@@ -26,45 +26,66 @@ MODULE_PARM_DESC(cards_dbg, set debug level
(info=1, adv=2 (or-able)));
static struct sms_board sms_boards[] = {
[SMS_BOARD_UNKNOWN] = {
- .name = Unknown board,
+ /* 0 */
+ .name = Unknown board,
+ .type = SMS_UNKNOWN_TYPE,
+ .default_mode = DEVICE_MODE_NONE,
},
[SMS1XXX_BOARD_SIANO_STELLAR] = {
- .name = Siano Stellar Digital Receiver,
- .type = SMS_STELLAR,
+ /* 1 */
+ .name =
+ Siano Stellar Digital Receiver,
+ .type = SMS_STELLAR,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
},
[SMS1XXX_BOARD_SIANO_NOVA_A] = {
- .name = Siano Nova A Digital Receiver,
- .type = SMS_NOVA_A0,
+ /* 2 */
+ .name = Siano Nova A Digital Receiver,
+ .type = SMS_NOVA_A0,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
},
[SMS1XXX_BOARD_SIANO_NOVA_B] = {
- .name = Siano Nova B Digital Receiver,
- .type = SMS_NOVA_B0,
+ /* 3 */
+ .name = Siano Nova B Digital Receiver,
+ .type = SMS_NOVA_B0,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
},
[SMS1XXX_BOARD_SIANO_VEGA] = {
- .name = Siano Vega Digital Receiver,
- .type = SMS_VEGA,
+ /* 4 */
+ .name = Siano Vega Digital Receiver,
+ .type = SMS_VEGA,
+ .default_mode = DEVICE_MODE_CMMB,
},
[SMS1XXX_BOARD_HAUPPAUGE_CATAMOUNT] = {
- .name = Hauppauge Catamount,
- .type = SMS_STELLAR,
- .fw[DEVICE_MODE_DVBT_BDA] =
sms1xxx-stellar-dvbt-01.fw,
+ /* 5 */
+ .name = Hauppauge Catamount,
+ .type = SMS_STELLAR,
+ .fw[DEVICE_MODE_DVBT_BDA] =
+ sms1xxx-stellar-dvbt-01.fw,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
},
[SMS1XXX_BOARD_HAUPPAUGE_OKEMO_A] = {
- .name = Hauppauge Okemo-A,
- .type = SMS_NOVA_A0,
- .fw[DEVICE_MODE_DVBT_BDA] = sms1xxx-nova-a-dvbt-01.fw,
+ /* 6 */
+ .name = Hauppauge Okemo-A,
+ .type = SMS_NOVA_A0,
+ .fw[DEVICE_MODE_DVBT_BDA] =
+ sms1xxx-nova-a-dvbt-01.fw,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
},
[SMS1XXX_BOARD_HAUPPAUGE_OKEMO_B] = {
- .name = Hauppauge Okemo-B,
- .type = SMS_NOVA_B0,
- .fw[DEVICE_MODE_DVBT_BDA] = sms1xxx-nova-b-dvbt-01.fw,
+ /* 7 */
+ .name = Hauppauge Okemo-B,
+ .type = SMS_NOVA_B0,
+ .fw[DEVICE_MODE_DVBT_BDA] =
+ sms1xxx-nova-b-dvbt-01.fw,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
},
[SMS1XXX_BOARD_HAUPPAUGE_WINDHAM] = {
- .name = Hauppauge WinTV MiniStick,
- .type = SMS_NOVA_B0,
- .fw[DEVICE_MODE_ISDBT_BDA] =
sms1xxx-hcw-55xxx-isdbt-02.fw,
+ /* 8 */
+ .name = Hauppauge WinTV MiniStick,
+ .type = SMS_NOVA_B0,
.fw[DEVICE_MODE_DVBT_BDA] =
sms1xxx-hcw-55xxx-dvbt-02.fw,
- .rc_codes = RC_MAP_HAUPPAUGE,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
.board_cfg.leds_power = 26,
.board_cfg.led0 = 27,
.board_cfg.led1 = 28,
@@ -74,30 +95,92 @@ static struct sms_board sms_boards[] = {
.led_hi= 28,
},
[SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD] = {
+ /* 9 */
.name = Hauppauge WinTV MiniCard,
.type = SMS_NOVA_B0,
.fw[DEVICE_MODE_DVBT_BDA] =
sms1xxx-hcw-55xxx-dvbt-02.fw,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
.lna_ctrl = 29,
.board_cfg.foreign_lna0_ctrl = 29,
.rf_switch = 17,
.board_cfg.rf_switch_uhf = 17,
},
Re: [alsa-devel] [patch][saa7134] do not change mute state for capturing audio
On Tue, 19.07.11 10:31, Stas Sergeev (s...@list.ru) wrote: 2. Even if it sucks in general. In this case, what solution would you propose to get the problem of the white noise fixed? Well, for removing the probing in PA we'd need a way to reliably figure out in which combinations of input and output we can open a sound card. i.e. we want to know if we can run surround 5.1 output and spdif output at the same time, or surround 5.1 output and stereo input and so on. And we'd need a lot of other attrbites about the sound card, and all that without having to open any PCM device. But that would be really hard to do, the current format neagotiation in ALSA PCM works very differently. And that's the reason why so far nobody has bothered with getting this right. The current code in PA to figure this out is somewhat ugly. It's slow, since we open the card in a lot of different combinations to test what works. It's fragile, since if somebody else has opened the soundcard we get an EBUSY which we take as hint that a specific combination didn't work, and so on. It's a hard problem, Lennart -- Lennart Poettering - Red Hat, Inc. -- 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: FW: [PATCH] drivers: support new Siano tuner devices.
Em 19-07-2011 08:35, Jesper Juhl escreveu:
Adding linux-media@vger.kernel.org to CC
Thanks, Jesper!
On Tue, 19 Jul 2011, Doron Cohen wrote:
Hi,
This is the first time I ever post changes to linux kernel, so excuse me
if I have errors in the process.
As Siano team member, I would like to update the drivers for Siano
devices with the latest and greatest fixes. Unfortunately there is a hug
gap between the current code in the kernel and the code Siano has which
is more advanced and supports newer devices. I will try to break down
the changes into small pieces so each of the changes will be clear and
isolated.
Here is the first change which is my test balloon and includes simple
changes which includes support in new devices pulished after the kernel
source maintenance has stopped.
Hi Doron,
Breaking them into one patch per logical change is the right thing to do.
We have several documents at linux Documentation/ that helps newer contributors
to understand how things work. The main ones are also at our wiki:
http://linuxtv.org/wiki/index.php/Developer_Section
For each patch you post, you should use as the subject, a one line description
of what the patch is doing, like:
siano: add new tuner devices
At the body, a long description describing why and how (except if the patch is
really trivial), followed by your Signed-off-by, as described at:
http://linuxtv.org/wiki/index.php/Development:_Submitting_Patches#Developer.27s_Certificate_of_Origin_1.1
If you need to add extra notes for the reviewers/maintainer, you can add it,
after
the description, prepended with ---. So, the email body will look like:
Include newer sms1xxx boards
Signed-off-by: Doron Cohen dor...@siano-ms.com
---
some comment that I don't want to go to the kernel for whatever reason
--- a/drivers/media/dvb/siano/sms-cards.c
+++ b/drivers/media/dvb/siano/sms-cards.c
@@ -26,45 +26,66 @@ MODULE_PARM_DESC(cards_dbg, set debug level (info=1, adv=2
(or-able)));
PS.: if you are not the patch author, you should add a From: at the first line
of the email
body to say so.
diff --git a/drivers/media/dvb/siano/sms-cards.c
b/drivers/media/dvb/siano/sms-cards.c
index af121db..302a9e3 100644
--- a/drivers/media/dvb/siano/sms-cards.c
+++ b/drivers/media/dvb/siano/sms-cards.c
@@ -26,45 +26,66 @@ MODULE_PARM_DESC(cards_dbg, set debug level
(info=1, adv=2 (or-able)));
Your emailer is not handling patches well: it is breaking long lines, damaging
it.
You need either to fix it by removing long line breaks or to use another
emailer.
static struct sms_board sms_boards[] = {
[SMS_BOARD_UNKNOWN] = {
- .name = Unknown board,
+ /* 0 */
Why do you need to add a sequence number?
+ .name = Unknown board,
Please, don't mix pure whitespace changes with other things.
It makes harder to analyze what really changed.
+ .type = SMS_UNKNOWN_TYPE,
+ .default_mode = DEVICE_MODE_NONE,
},
[SMS1XXX_BOARD_SIANO_STELLAR] = {
- .name = Siano Stellar Digital Receiver,
- .type = SMS_STELLAR,
+ /* 1 */
+ .name =
+ Siano Stellar Digital Receiver,
+ .type = SMS_STELLAR,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
},
[SMS1XXX_BOARD_SIANO_NOVA_A] = {
- .name = Siano Nova A Digital Receiver,
- .type = SMS_NOVA_A0,
+ /* 2 */
+ .name = Siano Nova A Digital Receiver,
+ .type = SMS_NOVA_A0,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
},
[SMS1XXX_BOARD_SIANO_NOVA_B] = {
- .name = Siano Nova B Digital Receiver,
- .type = SMS_NOVA_B0,
+ /* 3 */
+ .name = Siano Nova B Digital Receiver,
+ .type = SMS_NOVA_B0,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
},
[SMS1XXX_BOARD_SIANO_VEGA] = {
- .name = Siano Vega Digital Receiver,
- .type = SMS_VEGA,
+ /* 4 */
+ .name = Siano Vega Digital Receiver,
+ .type = SMS_VEGA,
+ .default_mode = DEVICE_MODE_CMMB,
},
[SMS1XXX_BOARD_HAUPPAUGE_CATAMOUNT] = {
- .name = Hauppauge Catamount,
- .type = SMS_STELLAR,
- .fw[DEVICE_MODE_DVBT_BDA] =
sms1xxx-stellar-dvbt-01.fw,
+ /* 5 */
+ .name = Hauppauge Catamount,
+ .type = SMS_STELLAR,
+ .fw[DEVICE_MODE_DVBT_BDA] =
+ sms1xxx-stellar-dvbt-01.fw,
+ .default_mode = DEVICE_MODE_DVBT_BDA,
},
[SMS1XXX_BOARD_HAUPPAUGE_OKEMO_A] = {
- .name = Hauppauge Okemo-A,
- .type = SMS_NOVA_A0,
- .fw[DEVICE_MODE_DVBT_BDA] = sms1xxx-nova-a-dvbt-01.fw,
+ /* 6 */
+ .name = Hauppauge Okemo-A,
+ .type =
Re: [patch][saa7134] do not change mute state for capturing audio
Em 18-07-2011 20:16, Lennart Poettering escreveu: Heya, On 17.07.2011 13:51, Mauro Carvalho Chehab wrote: If pulseaudio is starting sound capture at startup, then it is either a pulseaudio miss-configuration or a bug there. I fail to understand why pulseaudio would start capturing sound from a V4L audio at startup. I think that this is not the default for pulseaudio, though, as you're the only one complaining about that, and I never saw such behavior in the time I was using pulseaudio here. I don't know enough about pulseaudio to help on this issue, nor I'm using it currently, so I can't test anything pulsaudio-related. Lennart, Could you please help us with this issue? ALSA doesn't really have a enumeration API which would allow us to get device properties without opening and configuring a device. In fact, we can't even figure out whether a device may be opened in duplex or simplex without opening it. And that's why we have to probe audio devices, even if it sucks. Lennart, The thing is that starting capture on a video device has some side effects, as it will start capturing from a radio or TV station without specifying the desired frequency. Several video boards have the option of plugging a loop cable between the device output pin and the motherboard line in pin. So, if you start capturing, you'll also enabling the output of such pin, as the kernel driver has no way to know if the user decided to use a wire cable, instead of the ALSA PCM stream. So, if users with such cables are lucky, it will play something, but, on most cases, it will just tune into a non-existing station, and it will produce a white noise. The right thing to do is to get rid of capturing on a video device, if you're not sure that the device is properly tuned. It is easy to detect that an audio device is provided by a v4l device. All you need to do is to look at the parent device via sysfs. 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: [alsa-devel] [patch][saa7134] do not change mute state for capturing audio
On Tue, 19.07.11 10:00, Mauro Carvalho Chehab (mche...@infradead.org) wrote: Heya, The thing is that starting capture on a video device has some side effects, as it will start capturing from a radio or TV station without specifying the desired frequency. Several video boards have the option of plugging a loop cable between the device output pin and the motherboard line in pin. So, if you start capturing, you'll also enabling the output of such pin, as the kernel driver has no way to know if the user decided to use a wire cable, instead of the ALSA PCM stream. So, if users with such cables are lucky, it will play something, but, on most cases, it will just tune into a non-existing station, and it will produce a white noise. The right thing to do is to get rid of capturing on a video device, if you're not sure that the device is properly tuned. It is easy to detect that an audio device is provided by a v4l device. All you need to do is to look at the parent device via sysfs. So what we actually support in PA, is that you can disable the probing for specific sound cards if you supply a file that describes what should be exposed in PA for the sound card instead. We use that for a number of pro audio cards, where we want to show nicer human readable strings for specific configurations. This is configured in /usr/share/pulseaudio/alsa-mixer/paths/, /usr/share/pulseaudio/alsa-mixer/profile-sets/* and /lib/udev/rules.d/90-pulseaudio.rules. The udev rules files binds a profile set to a specific sound device. The profile set then declares in which combinations a sound card can be opened for input and output, and which mixer paths to expose. Note that the profile sets/mixer paths are supposed to be user-friendly. Hence instead of exposing all options they are designed to expose only the minimum that is useful in the UI. And the emphasis is on usefulness here, so the options the user can choose should be few, not overwhlemingly many. https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-June/004229.html It might make sense to add that for your TV card to PA as well. Lennart -- Lennart Poettering - Red Hat, Inc. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] mt9m111: move lastpage to struct mt9m111 for multi instances
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
---
v1 - v2: added initial value -1 for lastpage
drivers/media/video/mt9m111.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index a357aa8..07af26e 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -184,6 +184,7 @@ struct mt9m111 {
struct mutex power_lock; /* lock to protect power_count */
int power_count;
const struct mt9m111_datafmt *fmt;
+ int lastpage; /* PageMap cache value */
unsigned int gain;
unsigned char autoexposure;
unsigned char datawidth;
@@ -202,17 +203,17 @@ static int reg_page_map_set(struct i2c_client *client,
const u16 reg)
{
int ret;
u16 page;
- static int lastpage = -1; /* PageMap cache value */
+ struct mt9m111 *mt9m111 = to_mt9m111(client);
page = (reg 8);
- if (page == lastpage)
+ if (page == mt9m111-lastpage)
return 0;
if (page 2)
return -EINVAL;
ret = i2c_smbus_write_word_data(client, MT9M111_PAGE_MAP, swab16(page));
if (!ret)
- lastpage = page;
+ mt9m111-lastpage = page;
return ret;
}
@@ -932,6 +933,8 @@ static int mt9m111_video_probe(struct soc_camera_device
*icd,
BUG_ON(!icd-parent ||
to_soc_camera_host(icd-parent)-nr != icd-iface);
+ mt9m111-lastpage = -1;
+
mt9m111-autoexposure = 1;
mt9m111-autowhitebalance = 1;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/3] Frame synchronisation events and support for them in the OMAP 3 ISP driver
Hi all, The OMAP 3 ISP driver implements an HS_VS event which is triggered when the reception of a frame begins. This functionality is very, very likely not specific to OMAP 3 ISP so it should be standardised. I have a few patches to do that. Additionally the next expected buffer sequence number is provided with the event, unlike earlier. There are a few open questions, however, and this is why I'm sending the set as RFC. 1) Other frame synchronisation events. The CCDC block in the OMAP 3 ISP is able to trigger interrupts at two chosen lines of the image. These naturally can be translated to events. The driver uses both of them internally at specific points of the frame. Nevertheless, there might be some use for these in user space. Other hardware might implement a number of these which wouldn't be used by the driver itself, but I don't know of that at the moment. On the other hand high resolution timers are also available in user space, so doing timing based on ISP provided events is not quite as important as before --- as long as there's one frame based event produced at a known time, such as V4L2_EVENT_FRAME_START. Frame end events may be produced as well. This is not exactly the same as just dequeueing the buffer at video node since the hardware may be able to produce events even in cases there are no buffers and if the very hardware block that processes the frame is not outputting it to memory, handling by further blocks takes more time, and thus delays the finishing of the buffer from the driver's queue. This is the reason why the name of the struct related to the event is v4l2_event_frame_sync rather than v4l2_event_frame_start. 2) Buffer sequence number location in the struct v4l2_event. the patches create a new structure called v4l2_event_frame_sync which contains just one field, buffer_sequence. Should buffer_sequence be part of this struct, or should it be part of v4l2_event directly, as the id field? Both buffer_sequence and id refer to another rather widely used concept in V4L2. Besides this, the first patch in the series moves the documentation of structs inside v4l2_event to VIDIOC_DQEVENT documentation. I think it belongs there rather than to VIDIOC_SUBSCRIBE_EVENT, since that's not where they are being used. -- 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
[RFC 1/3] v4l: Move event documentation from SUBSCRIBE_EVENT to DQEVENT
Move documentation of structures used in DQEVENT from SUBSCRIBE_EVENT to DQEVENT. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 107 .../DocBook/media/v4l/vidioc-subscribe-event.xml | 107 2 files changed, 107 insertions(+), 107 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml index 7769642..5200b68 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml @@ -135,6 +135,113 @@ /tgroup /table +table frame=none pgwide=1 id=v4l2-event-vsync + titlestruct structnamev4l2_event_vsync/structname/title + tgroup cols=3 + cs-str; + tbody valign=top + row + entry__u8/entry + entrystructfieldfield/structfield/entry + entryThe upcoming field. See v4l2-field;./entry + /row + /tbody + /tgroup +/table + +table frame=none pgwide=1 id=v4l2-event-ctrl + titlestruct structnamev4l2_event_ctrl/structname/title + tgroup cols=4 + cs-str; + tbody valign=top + row + entry__u32/entry + entrystructfieldchanges/structfield/entry + entry/entry + entryA bitmask that tells what has changed. See xref linkend=changes-flags /./entry + /row + row + entry__u32/entry + entrystructfieldtype/structfield/entry + entry/entry + entryThe type of the control. See v4l2-ctrl-type;./entry + /row + row + entryunion (anonymous)/entry + entry/entry + entry/entry + entry/entry + /row + row + entry/entry + entry__s32/entry + entrystructfieldvalue/structfield/entry + entryThe 32-bit value of the control for 32-bit control types. + This is 0 for string controls since the value of a string + cannot be passed using VIDIOC-DQEVENT;./entry + /row + row + entry/entry + entry__s64/entry + entrystructfieldvalue64/structfield/entry + entryThe 64-bit value of the control for 64-bit control types./entry + /row + row + entry__u32/entry + entrystructfieldflags/structfield/entry + entry/entry + entryThe control flags. See xref linkend=control-flags /./entry + /row + row + entry__s32/entry + entrystructfieldminimum/structfield/entry + entry/entry + entryThe minimum value of the control. See v4l2-queryctrl;./entry + /row + row + entry__s32/entry + entrystructfieldmaximum/structfield/entry + entry/entry + entryThe maximum value of the control. See v4l2-queryctrl;./entry + /row + row + entry__s32/entry + entrystructfieldstep/structfield/entry + entry/entry + entryThe step value of the control. See v4l2-queryctrl;./entry + /row + row + entry__s32/entry + entrystructfielddefault_value/structfield/entry + entry/entry + entryThe default value value of the control. See v4l2-queryctrl;./entry + /row + /tbody + /tgroup +/table + +table pgwide=1 frame=none id=changes-flags + titleChanges/title + tgroup cols=3 + cs-def; + tbody valign=top + row + entryconstantV4L2_EVENT_CTRL_CH_VALUE/constant/entry + entry0x0001/entry + entryThis control event was triggered because the value of the control + changed. Special case: if a button control is pressed, then this + event is sent as well, even though there is not explicit value + associated with a button control./entry + /row + row + entryconstantV4L2_EVENT_CTRL_CH_FLAGS/constant/entry + entry0x0002/entry + entryThis control event was triggered because the control flags + changed./entry + /row + /tbody + /tgroup +/table /refsect1 refsect1 return-value; diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index 69c0d8a..275be96 100644 --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml @@ -183,113 +183,6 @@ /tgroup /table -table frame=none pgwide=1 id=v4l2-event-vsync - titlestruct structnamev4l2_event_vsync/structname/title - tgroup cols=3 - cs-str; - tbody valign=top - row - entry__u8/entry - entrystructfieldfield/structfield/entry - entryThe
[RFC 3/3] omap3isp: ccdc: Make frame start event generic
The ccdc block in the omap3isp produces frame start events. These events
were previously specific to the omap3isp. Make them generic.
Also add sequence number to the frame. This is stored to the id field.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
Documentation/video4linux/omap3isp.txt |9 +
drivers/media/video/omap3isp/ispccdc.c |7 +--
include/linux/omap3isp.h |2 --
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/Documentation/video4linux/omap3isp.txt
b/Documentation/video4linux/omap3isp.txt
index 69be2c7..84f24cf 100644
--- a/Documentation/video4linux/omap3isp.txt
+++ b/Documentation/video4linux/omap3isp.txt
@@ -70,10 +70,11 @@ Events
The OMAP 3 ISP driver does support the V4L2 event interface on CCDC and
statistics (AEWB, AF and histogram) subdevs.
-The CCDC subdev produces V4L2_EVENT_OMAP3ISP_HS_VS type event on HS_VS
-interrupt which is used to signal frame start. The event is triggered exactly
-when the reception of the first line of the frame starts in the CCDC module.
-The event can be subscribed on the CCDC subdev.
+The CCDC subdev produces V4L2_EVENT_FRAME_START type event on HS_VS
+interrupt which is used to signal frame start. Earlier version of this
+driver used V4L2_EVENT_OMAP3ISP_HS_VS for this purpose. The event is
+triggered exactly when the reception of the first line of the frame starts
+in the CCDC module. The event can be subscribed on the CCDC subdev.
(When using parallel interface one must pay account to correct configuration
of the VS signal polarity. This is automatically correct when using the serial
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c
index 6766247..61c9e3d 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -1402,11 +1402,14 @@ static int __ccdc_handle_stopping(struct
isp_ccdc_device *ccdc, u32 event)
static void ccdc_hs_vs_isr(struct isp_ccdc_device *ccdc)
{
+ struct isp_pipeline *pipe =
+ to_isp_pipeline(ccdc-video_out.video.entity);
struct video_device *vdev = ccdc-subdev.devnode;
struct v4l2_event event;
memset(event, 0, sizeof(event));
- event.type = V4L2_EVENT_OMAP3ISP_HS_VS;
+ event.type = V4L2_EVENT_FRAME_START;
+ event.u.frame_sync.buffer_sequence = atomic_read(pipe-frame_number);
v4l2_event_queue(vdev, event);
}
@@ -1688,7 +1691,7 @@ static long ccdc_ioctl(struct v4l2_subdev *sd, unsigned
int cmd, void *arg)
static int ccdc_subscribe_event(struct v4l2_subdev *sd, struct v4l2_fh *fh,
struct v4l2_event_subscription *sub)
{
- if (sub-type != V4L2_EVENT_OMAP3ISP_HS_VS)
+ if (sub-type != V4L2_EVENT_FRAME_START)
return -EINVAL;
return v4l2_event_subscribe(fh, sub, OMAP3ISP_CCDC_NEVENTS);
diff --git a/include/linux/omap3isp.h b/include/linux/omap3isp.h
index b6111f8..c73a34c 100644
--- a/include/linux/omap3isp.h
+++ b/include/linux/omap3isp.h
@@ -62,14 +62,12 @@
* V4L2_EVENT_OMAP3ISP_AEWB: AEWB statistics data ready
* V4L2_EVENT_OMAP3ISP_AF: AF statistics data ready
* V4L2_EVENT_OMAP3ISP_HIST: Histogram statistics data ready
- * V4L2_EVENT_OMAP3ISP_HS_VS: Horizontal/vertical synchronization detected
*/
#define V4L2_EVENT_OMAP3ISP_CLASS (V4L2_EVENT_PRIVATE_START | 0x100)
#define V4L2_EVENT_OMAP3ISP_AEWB (V4L2_EVENT_OMAP3ISP_CLASS | 0x1)
#define V4L2_EVENT_OMAP3ISP_AF (V4L2_EVENT_OMAP3ISP_CLASS | 0x2)
#define V4L2_EVENT_OMAP3ISP_HIST (V4L2_EVENT_OMAP3ISP_CLASS | 0x3)
-#define V4L2_EVENT_OMAP3ISP_HS_VS (V4L2_EVENT_OMAP3ISP_CLASS | 0x4)
struct omap3isp_stat_event_status {
__u32 frame_number;
--
1.7.2.5
--
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 2/3] v4l: events: Define frame start event
Define a frame start event to tell user space when the reception of a frame
starts.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 26
.../DocBook/media/v4l/vidioc-subscribe-event.xml | 18 +
include/linux/videodev2.h | 12 +++--
3 files changed, 53 insertions(+), 3 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
index 5200b68..d2cb8db 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -88,6 +88,12 @@
/row
row
entry/entry
+ entryv4l2-event-frame-sync;/entry
+entrystructfieldframe/structfield/entry
+ entryEvent data for event V4L2_EVENT_FRAME_START./entry
+ /row
+ row
+ entry/entry
entry__u8/entry
entrystructfielddata/structfield[64]/entry
entryEvent data. Defined by the event type. The union
@@ -220,6 +226,26 @@
/tgroup
/table
+table frame=none pgwide=1 id=v4l2-event-frame-sync
+ titlestruct structnamev4l2_event_frame_sync/structname/title
+ tgroup cols=3
+ cs-str;
+ tbody valign=top
+ row
+ entry__u32/entry
+ entrystructfieldbuffer_sequence/structfield/entry
+ entry
+ The sequence number of the buffer to be handled next or
+ currently handled by the driver.
+ /entry
+ /row
+ /tbody
+ /tgroup
+/table
+
+parav4l2-event-frame-sync; is associated with
+constantV4L2_EVENT_FRAME_START/constant event./para
+
table pgwide=1 frame=none id=changes-flags
titleChanges/title
tgroup cols=3
diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
index 275be96..7ec42bb 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -139,6 +139,24 @@
/entry
/row
row
+ entryconstantV4L2_EVENT_FRAME_START/constant/entry
+ entry4/entry
+ entry
+ paraTriggered immediately when the reception of a
+ frame has begun. This event has a
+ v4l2-event-frame-sync; associated with it./para
+
+ paraA driver will only generate this event when the
+ hardware can generate it. This might not be the case
+ e.g. when the hardware has no DMA buffer to write the
+ image data to. In such cases the
+ structfieldbuffer_sequence/structfield field in
+ v4l2-event-frame-sync; will not be incremented either.
+ This causes two consecutive buffer sequence numbers to
+ have n times frame interval in between them./para
+ /entry
+ /row
+ row
entryconstantV4L2_EVENT_PRIVATE_START/constant/entry
entry0x0800/entry
entryBase event number for driver-private events./entry
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..4265102 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2006,6 +2006,7 @@ struct v4l2_streamparm {
#define V4L2_EVENT_VSYNC 1
#define V4L2_EVENT_EOS 2
#define V4L2_EVENT_CTRL3
+#define V4L2_EVENT_FRAME_START 4
#define V4L2_EVENT_PRIVATE_START 0x0800
/* Payload for V4L2_EVENT_VSYNC */
@@ -2032,12 +2033,17 @@ struct v4l2_event_ctrl {
__s32 default_value;
};
+struct v4l2_event_frame_sync {
+ __u32 buffer_sequence;
+};
+
struct v4l2_event {
__u32 type;
union {
- struct v4l2_event_vsync vsync;
- struct v4l2_event_ctrl ctrl;
- __u8data[64];
+ struct v4l2_event_vsync vsync;
+ struct v4l2_event_ctrl ctrl;
+ struct v4l2_event_frame_syncframe_sync;
+ __u8data[64];
} u;
__u32 pending;
__u32 sequence;
--
1.7.2.5
--
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][saa7134] do not change mute state for capturing audio
19.07.2011 17:00, Mauro Carvalho Chehab wrote: Several video boards have the option of plugging a loop cable between the device output pin and the motherboard line in pin. So, if you start capturing, you'll also enabling the output of such pin, as the kernel driver has no way to know if the user decided to use a wire cable, instead of the ALSA PCM stream. So, if users with such cables are lucky, it will play something, but, on most cases, it will just tune into a non-existing station, and it will produce a white noise. This needs to be clarified a bit (for Lennart). Initially, before the board is tuned to some station, the sound is wisely muted. It is muted for both the capturing and the pass-through cable. As far as I can tell, if you want to probe the card by capturing, you can capture the silence, you don't need any real sound to record. The problem here is that the particular driver has a nice code (or a hack) that unmutes both the capturing and the pass-through cable when you capture anything. From my POV, exactly that leads to the problem. Simply removing that piece of code makes the peace in the world: the app that tunes the board, also unmutes the sound anyway. My question was and still is: do we need to search for any other solution at all? Do we need to modify PA, if it is entirely fine with capturing the silence for probing audio? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mt9m111: move lastpage to struct mt9m111 for multi instances
Hi Michael
Looks good now, thanks. Unfortunately, we've already missed the 3.1 merge
window, unless Linus decides to release one more 3.0-rcX kernel. But
still, I think, this can qualify as a fix, so, it should be ok even after
-rc1.
Thanks
Guennadi
On Tue, 19 Jul 2011, Michael Grzeschik wrote:
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
---
v1 - v2: added initial value -1 for lastpage
drivers/media/video/mt9m111.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index a357aa8..07af26e 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -184,6 +184,7 @@ struct mt9m111 {
struct mutex power_lock; /* lock to protect power_count */
int power_count;
const struct mt9m111_datafmt *fmt;
+ int lastpage; /* PageMap cache value */
unsigned int gain;
unsigned char autoexposure;
unsigned char datawidth;
@@ -202,17 +203,17 @@ static int reg_page_map_set(struct i2c_client *client,
const u16 reg)
{
int ret;
u16 page;
- static int lastpage = -1; /* PageMap cache value */
+ struct mt9m111 *mt9m111 = to_mt9m111(client);
page = (reg 8);
- if (page == lastpage)
+ if (page == mt9m111-lastpage)
return 0;
if (page 2)
return -EINVAL;
ret = i2c_smbus_write_word_data(client, MT9M111_PAGE_MAP, swab16(page));
if (!ret)
- lastpage = page;
+ mt9m111-lastpage = page;
return ret;
}
@@ -932,6 +933,8 @@ static int mt9m111_video_probe(struct soc_camera_device
*icd,
BUG_ON(!icd-parent ||
to_soc_camera_host(icd-parent)-nr != icd-iface);
+ mt9m111-lastpage = -1;
+
mt9m111-autoexposure = 1;
mt9m111-autowhitebalance = 1;
--
1.7.5.4
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch][saa7134] do not change mute state for capturing audio
Em 19-07-2011 10:49, Stas Sergeev escreveu: 19.07.2011 17:00, Mauro Carvalho Chehab wrote: Several video boards have the option of plugging a loop cable between the device output pin and the motherboard line in pin. So, if you start capturing, you'll also enabling the output of such pin, as the kernel driver has no way to know if the user decided to use a wire cable, instead of the ALSA PCM stream. So, if users with such cables are lucky, it will play something, but, on most cases, it will just tune into a non-existing station, and it will produce a white noise. This needs to be clarified a bit (for Lennart). Initially, before the board is tuned to some station, the sound is wisely muted. It is muted for both the capturing and the pass-through cable. As far as I can tell, if you want to probe the card by capturing, you can capture the silence, you don't need any real sound to record. The problem here is that the particular driver has a nice code (or a hack) that unmutes both the capturing and the pass-through cable when you capture anything. It is not something for a particular driver. All v4l alsa drivers have similar logic: they assume that, if some application is streaming, the device should be unmuted, otherwise capture won't work. From my POV, exactly that leads to the problem. Simply removing that piece of code makes the peace in the world: the app that tunes the board, also unmutes the sound anyway. It is not clear, from an application POV, to know what audio pin should be unmuted. Some devices, like, for example, em28xx may have an ac97 connected on it, with lots of muxes on it. For each different video input port, a different mixer set should be used, and the configuration is board-dependent. For example, on Prolink PlayTV USB2, this is wired as: AC97 mono volume = PCM output AC97 master volume = Line out pin AC97 video volume = TV tuner input AC97 line in volume = Svideo or composite input As this is an USB device, in general, people don't connect the line out pin. So, typically, in order to unmute this particular device for TV, one should unmute both AC97 MONO and AC97 VIDEO, and mute AC97 LINE IN. If the application latter changes to SVideo, the AC97 VIDEO should be muted, and AC97 LINE IN should be unmuted. There's no way for an userspace application to know that, since: 1) The device internal connections are not visible on userspace; 2) This is board-dependent. For example, Supercomp USB 2.0 TV has just the opposite setup for TV/svideo: AC97 video volume = Svideo or Composite Input AC97 line in volume = TV Input and doesn't have any output volume connected. 3) On some cases, there are two or even three mutes that need to be changed. Moving such logic to happen at userspace would be very complex, and will break existing applications. Cheers, Mauro. My question was and still is: do we need to search for any other solution at all? Do we need to modify PA, if it is entirely fine with capturing the silence for probing audio? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch][saa7134] do not change mute state for capturing audio
19.07.2011 18:10, Mauro Carvalho Chehab wrote: As this is an USB device, in general, people don't connect the line out pin. So, typically, in order to unmute this particular device for TV, one should unmute both AC97 MONO and AC97 VIDEO, and mute AC97 LINE IN. If the application latter changes to SVideo, the AC97 VIDEO should be muted, and AC97 LINE IN should be unmuted. Unless I am missing the point, you need some mixer control that will just unmute the currently-configured things. If you can unmute all the right things when an app just starts capturing, then you can as well unmute the same things by that _single_ mixer control. And if the app changes the output to SVideo, as in your example, you can first mute everything, and then unmute the new lines, but only if the old lines were unmuted. IMHO, that logic will not break the existing apps. Moving such logic to happen at userspace would be very complex, and will break existing applications. If this is the case, then how does the simplest xawtv's mute/unmute thing works with all these boards right now? (not that I have checked it does, but I hope so. :) -- 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][saa7134] do not change mute state for capturing audio
Em 19-07-2011 11:56, Stas Sergeev escreveu: 19.07.2011 18:10, Mauro Carvalho Chehab wrote: As this is an USB device, in general, people don't connect the line out pin. So, typically, in order to unmute this particular device for TV, one should unmute both AC97 MONO and AC97 VIDEO, and mute AC97 LINE IN. If the application latter changes to SVideo, the AC97 VIDEO should be muted, and AC97 LINE IN should be unmuted. Unless I am missing the point, you need some mixer control that will just unmute the currently-configured things. If you can unmute all the right things when an app just starts capturing, then you can as well unmute the same things by that _single_ mixer control. And if the app changes the output to SVideo, as in your example, you can first mute everything, and then unmute the new lines, but only if the old lines were unmuted. IMHO, that logic will not break the existing apps. That is the current logic, except that we don't create an additional virtual mixer control like the one you've proposed via ALSA API. The business logic coded into the Kernel is that, when audio stream is started or a different input is selected, the driver checks the current applicable mute/volumes and sets the pertinent ones to unmute, muting the others. Yet, they allow users to manually adjust the volume controls, as someone may want for example to use the mixer to mix the original TV audio with a microphone, for example, connected at the LINE IN input that some boards offer. Also, some newer devices are coming with the capability of mixing video inputs (s5p driver recently added a video mixer). It makes sense for applications that use it, to also allow controlling the audio mixer. That's basically why we want to expose such controls to userspace: to allow users to control the audio mixer when they need, for whatever reason. If I understood PA concepts, its philosophy seems to hide those controls that aren't meant to be used by the default usecase. As such, it should not be exposing any mixer/mute at all from a V4L device. The proper fix seems to make PA to use libmedia_dev[1] to detect what audio input devices are associated with a V4L board and removing them for the list of controlled devices by default, eventually allowing the users to add them again via some configuration parameter. [1] http://git.linuxtv.org/v4l-utils.git?a=blob;f=utils/libmedia_dev/README Moving such logic to happen at userspace would be very complex, and will break existing applications. If this is the case, then how does the simplest xawtv's mute/unmute thing works with all these boards right now? (not that I have checked it does, but I hope so. :) Xawtv mute/unmute probably needs fix. It uses 3 different API's for that: V4L2, ALSA and OSS. Most of the logic there is for OSS, witch can be removed nowadays. Feel free to submit patches for it. Yet, as you may be aware of that, the V4L2 API offers a few audio controls (volume, mute, balance, bass, treble), that applies to the current stream, on the drivers that provide them. So, a video application may opt to not control the alsa mixers directly, but, instead, use the V4L2 controls. Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch][saa7134] do not change mute state for capturing audio
19.07.2011 19:27, Mauro Carvalho Chehab wrote: Unless I am missing the point, you need some mixer control that will just unmute the currently-configured things. If you can unmute all the right things when an app just starts capturing, then you can as well unmute the same things by that _single_ mixer control. And if the app changes the output to SVideo, as in your example, you can first mute everything, and then unmute the new lines, but only if the old lines were unmuted. IMHO, that logic will not break the existing apps. That is the current logic, except that we don't create an additional virtual mixer control like the one you've proposed via ALSA API. Unless I am mistaken, this control is usually called a Master Playback Switch in the alsa world. So, am I right that the only problem is that it is not exported to the user by some drivers right now? And, if it is made exported, what will still prevent us from dropping the auto-unmute stuff? Yet, as you may be aware of that, the V4L2 API offers a few audio controls (volume, mute, balance, bass, treble), that applies to the current stream, on the drivers that provide them. So, a video application may opt to not control the alsa mixers directly, but, instead, use the V4L2 controls. In this case, I think, the alsa mixer control should just mirror the one of the v4l2 for the most cases. Maybe for some boards they can actually do the different things - doesn't matter right now though. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] imon: don't parse scancodes until intf configured
The imon devices have either 1 or 2 usb interfaces on them, each wired
up to its own urb callback. The interface 0 urb callback is wired up
before the imon context's rc_dev pointer is filled in, which is
necessary for imon 0xffdc device auto-detection to work properly, but we
need to make sure we don't actually run the callback routines until
we've entirely filled in the necessary bits for each given interface,
lest we wind up oopsing. Technically, any imon device could have hit
this, but the issue is exacerbated on the 0xffdc devices, which send a
constant stream of interrupts, even when they have no valid key data.
CC: Andy Walls awa...@md.metrocast.net
CC: Chris W l...@psychogeeks.com
Reported-by: Chris W l...@psychogeeks.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/rc/imon.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index caa3e3a..6ed9646 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -1658,7 +1658,7 @@ static void usb_rx_callback_intf0(struct urb *urb)
return;
ictx = (struct imon_context *)urb-context;
- if (!ictx)
+ if (!ictx || !ictx-dev_present_intf0)
return;
switch (urb-status) {
@@ -1690,7 +1690,7 @@ static void usb_rx_callback_intf1(struct urb *urb)
return;
ictx = (struct imon_context *)urb-context;
- if (!ictx)
+ if (!ictx || !ictx-dev_present_intf1)
return;
switch (urb-status) {
@@ -2118,7 +2118,6 @@ static struct imon_context *imon_init_intf0(struct
usb_interface *intf)
ictx-dev = dev;
ictx-usbdev_intf0 = usb_get_dev(interface_to_usbdev(intf));
- ictx-dev_present_intf0 = true;
ictx-rx_urb_intf0 = rx_urb;
ictx-tx_urb = tx_urb;
ictx-rf_device = false;
@@ -2157,6 +2156,8 @@ static struct imon_context *imon_init_intf0(struct
usb_interface *intf)
goto rdev_setup_failed;
}
+ ictx-dev_present_intf0 = true;
+
mutex_unlock(ictx-lock);
return ictx;
@@ -2200,7 +2201,6 @@ static struct imon_context *imon_init_intf1(struct
usb_interface *intf,
}
ictx-usbdev_intf1 = usb_get_dev(interface_to_usbdev(intf));
- ictx-dev_present_intf1 = true;
ictx-rx_urb_intf1 = rx_urb;
ret = -ENODEV;
@@ -2229,6 +2229,8 @@ static struct imon_context *imon_init_intf1(struct
usb_interface *intf,
goto urb_submit_failed;
}
+ ictx-dev_present_intf1 = true;
+
mutex_unlock(ictx-lock);
return ictx;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dvb-apps: Fix atsc_epg crash when title text length is zero
The ATSC A/65C standard (in Section 6.5) allows the title_length field
in the Event Information Table (EIT) to be set to zero, but the atsc_epg
program crashes with the following backtrace if that happens:
Core was generated by `./atsc_epg -t -f 52100'.
Program terminated with signal 11, Segmentation fault.
#0 0x080484b2 in atsc_text_strings_first (txt=0x0)
at ../../lib/libucsi/atsc/types.h:174
174 if (txt-number_strings == 0)
(gdb) bt
#0 0x080484b2 in atsc_text_strings_first (txt=0x0)
at ../../lib/libucsi/atsc/types.h:174
#1 0x08049670 in parse_events (curr_info=0x811bd4c, eit=0xbfcd0d78,
section=0x8302710) at atsc_epg.c:647
#2 0x08049be6 in parse_eit (dmxfd=4, index=1, pid=7425) at atsc_epg.c:806
#3 0x0804aa39 in main (argc=4, argv=0xbfcd1ee4) at atsc_epg.c:1197
This patch simply skips parsing title text data if title_length is zero.
Signed-off-by: Bob Ross pigi...@gmx.com
---
util/atsc_epg/atsc_epg.c |2 ++
1 file changed, 2 insertions(+)
diff -uprN dvb-apps.orig/util/atsc_epg/atsc_epg.c
dvb-apps/util/atsc_epg/atsc_epg.c
--- dvb-apps.orig/util/atsc_epg/atsc_epg.c 2011-07-01 20:32:30.0
-0500
+++ dvb-apps/util/atsc_epg/atsc_epg.c 2011-07-08 17:32:43.0 -0500
@@ -644,6 +644,8 @@ static int parse_events(struct atsc_chan
}
title = atsc_eit_event_name_title_text(e);
+ if (title == NULL)
+ continue;
atsc_text_strings_for_each(title, str, j) {
struct atsc_text_string_segment *seg;
--
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][saa7134] do not change mute state for capturing audio
Em 19-07-2011 12:50, Stas Sergeev escreveu: 19.07.2011 19:27, Mauro Carvalho Chehab wrote: Unless I am missing the point, you need some mixer control that will just unmute the currently-configured things. If you can unmute all the right things when an app just starts capturing, then you can as well unmute the same things by that _single_ mixer control. And if the app changes the output to SVideo, as in your example, you can first mute everything, and then unmute the new lines, but only if the old lines were unmuted. IMHO, that logic will not break the existing apps. That is the current logic, except that we don't create an additional virtual mixer control like the one you've proposed via ALSA API. Unless I am mistaken, this control is usually called a Master Playback Switch in the alsa world. No, you're mistaken: on most boards, you have only one volume control/switch, for capture. So, it would be a master capture switch, but I don't think that there's such alsa generic volume control. Even in the case where you have a volume control for the LINE OUT pin[1], in general, you also need to unmute the capture, so, it would be a master capture and LINE OUT switch, and, for sure alsa currently not provide anything like that. So, am I right that the only problem is that it is not exported to the user by some drivers right now? No, you're mistaken again. Such master capture and LINE OUT switch type of control _is_exported_ via the V4L2 API as V4L2_CID_AUDIO_MUTE. And, if it is made exported, what will still prevent us from dropping the auto-unmute stuff? Some applications like mplayer don't use V4L2_CID_AUDIO_MUTE to unmute a video device. They assume the current behavior that starting video also unmutes audio. (mplayer is not symmetric with regard to the usage of this control, as it uses V4L2_CID_AUDIO_MUTE to mute the device after the end of a capture). So, changing the logic at the drivers will break existing applications. It should be noticed that the alsa module is only enabled on devices that provides PCM output via the PCI or USB bus. On the other hand, the V4L2_CID_AUDIO_MUTE control is available for all devices that are capable of muting/unmuting the audio. That's why V4L applications rely on it, instead of using alsa mixers. I dunno what's your specific saa7134 device model, but, from what I understood, instead of using the PCM output, you're using the LINE OUT pin. It is probably doable to split the mute control for the LINE OUT pin from the mute control of the PCM capture. Such patch would make sense, as the alsa capture doesn't need to touch at the line out pin, but the patch should let V4L2_CID_AUDIO_MUTE control to affect both LINE OUT and PCM capture mutes, otherwise applications will break. Yet, as you may be aware of that, the V4L2 API offers a few audio controls (volume, mute, balance, bass, treble), that applies to the current stream, on the drivers that provide them. So, a video application may opt to not control the alsa mixers directly, but, instead, use the V4L2 controls. In this case, I think, the alsa mixer control should just mirror the one of the v4l2 for the most cases. Maybe for some boards they can actually do the different things - doesn't matter right now though. We need a solution that works for both simple and complex devices. - [1] IMHO, LINE OUT pin doesn't fit very well on playback/capture concept. The capture volume/switch controls the A/D circuits for capture, while the playblack controls the D/A circuits. However, the LINE OUT pin gets audio from the captured data, and doesn't allow to direct any other PCM data into the D/A. So, it is not a complete playback type of control. So, it won't fit at the Master Playback Switch type. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch][saa7134] do not change mute state for capturing audio
19.07.2011 22:06, Mauro Carvalho Chehab wrote: Unless I am mistaken, this control is usually called a Master Playback Switch in the alsa world. No, you're mistaken: on most boards, you have only one volume control/switch, for capture. So, it would be a master capture switch, Well, for such a cards we don't need to export the additional element, they are fine already. We can rename it to Master Capture Switch, or may not. but I don't think that there's such alsa generic volume control. Even in the case where you have a volume control for the LINE OUT pin[1], in general, you also need to unmute the capture, so, it would be a master capture and LINE OUT switch, and, for sure alsa currently not provide anything like that. I think you can still call it a Master Capture Switch, if it enables everything. So, am I right that the only problem is that it is not exported to the user by some drivers right now? No, you're mistaken again. Such master capture and LINE OUT switch type of control _is_exported_ via the V4L2 API as V4L2_CID_AUDIO_MUTE. Sorry, I meant the _alsa_ drivers here. So, to rephrase: So, am I right that the only problem is that it is not exported to the user by some _alsa_ drivers right now? Some applications like mplayer don't use V4L2_CID_AUDIO_MUTE to unmute a video device. They assume the current behavior that starting video also unmutes audio. (mplayer is not symmetric with regard to the usage of this control, as it uses V4L2_CID_AUDIO_MUTE to mute the device after the end of a capture). So, changing the logic at the drivers will break existing applications. I do not propose changing any V4L2 ioctls, my change concerns only the alsa driver. It is probably doable to split the mute control for the LINE OUT pin from the mute control of the PCM capture. Such patch would make sense, as the alsa capture doesn't need to touch at the line out pin, but the patch should let V4L2_CID_AUDIO_MUTE control to affect both LINE OUT and PCM capture mutes, otherwise applications will break. That's exactly what I was talking about from the very beginning, saying that the single control currently controls way too much, and providing an examples about 2 separate controls. But... I haven't found the way to implement that, not sure of this is possible at all. :( -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Jul 19 19:00:31 CEST 2011 git hash:9bc5f6fa12c9e3e1e73e66bfabe9d463ea779b08 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/8] davinci: vpfe: add dm3xx IPIPEIF hardware support module
Hadli, Manjunath wrote: Sakari, Thank you for your comments. I agree with them and fix. Please comment on the rest of the patches as well. -Manju Hi Manju, I'll attempt to find more time for this. [clip] +/* CFG1 Masks and shifts */ +#define ONESHOT_SHIFT (0) +#define DECIM_SHIFT(1) +#define INPSRC_SHIFT (2) +#define CLKDIV_SHIFT (4) +#define AVGFILT_SHIFT (7) +#define PACK8IN_SHIFT (8) +#define IALAW_SHIFT(9) +#define CLKSEL_SHIFT (10) +#define DATASFT_SHIFT (11) +#define INPSRC1_SHIFT (14) IPIPEIF prefix. Are these related to a particular register or a set of registers? One register. Will need to add the IPIPEIF prefix. Assuming CFG1 is the name of the register, what about IPIPEIF_CFG1_...? +/* DPC2 */ +#define IPIPEIF_DPC2_EN_SHIFT (12) +#define IPIPEIF_DPC2_THR_MASK (0xFFF) +#define IPIPEIF_DF_GAIN_EN_SHIFT (10) +#define IPIPEIF_DF_GAIN_MASK (0x3FF) +#define IPIPEIF_DF_GAIN_THR_MASK (0xFFF) Also all of these should have DPC2 prefix before DPC2 if they're all for the same register. Regards, -- Sakari Ailus sakari.ai...@iki.fi -- 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][saa7134] do not change mute state for capturing audio
Em 19-07-2011 15:38, Stas Sergeev escreveu: 19.07.2011 22:06, Mauro Carvalho Chehab wrote: Unless I am mistaken, this control is usually called a Master Playback Switch in the alsa world. No, you're mistaken: on most boards, you have only one volume control/switch, for capture. So, it would be a master capture switch, Well, for such a cards we don't need to export the additional element, they are fine already. We can rename it to Master Capture Switch, or may not. Adding a new volume control that changes the mute values for the other controls or renaming it don't solve anything. but I don't think that there's such alsa generic volume control. Even in the case where you have a volume control for the LINE OUT pin[1], in general, you also need to unmute the capture, so, it would be a master capture and LINE OUT switch, and, for sure alsa currently not provide anything like that. I think you can still call it a Master Capture Switch, if it enables everything. That would be wrong. So, am I right that the only problem is that it is not exported to the user by some drivers right now? No, you're mistaken again. Such master capture and LINE OUT switch type of control _is_exported_ via the V4L2 API as V4L2_CID_AUDIO_MUTE. Sorry, I meant the _alsa_ drivers here. So, to rephrase: So, am I right that the only problem is that it is not exported to the user by some _alsa_ drivers right now? I fail to see why this would be a problem. The problem I see is that PA is trying to handle a V4L device as if it would be a normal audio capture pin, and starting a capture while the device is not ready for that, as no input or TV/radio station were selected at the time PA starts capturing. Some applications like mplayer don't use V4L2_CID_AUDIO_MUTE to unmute a video device. They assume the current behavior that starting video also unmutes audio. (mplayer is not symmetric with regard to the usage of this control, as it uses V4L2_CID_AUDIO_MUTE to mute the device after the end of a capture). So, changing the logic at the drivers will break existing applications. I do not propose changing any V4L2 ioctls, my change concerns only the alsa driver. It is probably doable to split the mute control for the LINE OUT pin from the mute control of the PCM capture. Such patch would make sense, as the alsa capture doesn't need to touch at the line out pin, but the patch should let V4L2_CID_AUDIO_MUTE control to affect both LINE OUT and PCM capture mutes, otherwise applications will break. That's exactly what I was talking about from the very beginning, saying that the single control currently controls way too much, and providing an examples about 2 separate controls. But... I haven't found the way to implement that, not sure of this is possible at all. :( It is doable, although it is probably not trivial. Devices with saa7130 (PCI_DEVICE_ID_PHILIPS_SAA7130) doesn't enable the alsa module, as they don't support I2S transfers, required for PCM audio. So, we need to take care only on saa7133/4/5 devices. The mute code is at saa7134-tvaudio.c, mute_input_7134() function. For saa7134, it does: if (PCI_DEVICE_ID_PHILIPS_SAA7134 == dev-pci-device) /* 7134 mute */ saa_writeb(SAA7134_AUDIO_MUTE_CTRL, mute ? SAA7134_MUTE_MASK | SAA7134_MUTE_ANALOG | SAA7134_MUTE_I2S : SAA7134_MUTE_MASK); Clearly, there are two mute flags: SAA7134_MUTE_ANALOG and SAA7134_MUTE_I2S. I2S is for PCM (as it is a digital audio interface). The other flag is for analog. So, if the device is a saa7134, it is easy to split the analog output and the PCM one. For saa7133 and saa7135, you probably need to double check at the datasheet, is is there a way to disable/enable just the I2S interface, but, from saa7134_enable_i2s(): /* Start I2S */ saa_writeb(SAA7134_I2S_AUDIO_OUTPUT, 0x11); I bet that there is some value (maybe 0?) that disables I2S transfers, muting the PCM stream. It should be tested if saa7133/5 devices accept to enable/disable PCM streams if the device is already streaming. 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: Hauppauge model 73219 rev D1F5 tuner doesn't detect signal, older rev D1E9 works
On Tue, Jul 19, 2011 at 3:37 AM, Jesper Juhl j...@chaosbits.net wrote: Hi I have a bunch of Hauppauge HVR-1900 model 73219's, some are revision D1E9 and work perfectly, but with the newer revision D1F5's the tuner fails to detect a signal and consequently just gives me blank output on /dev/video0. Other input sources, like composite or s-video, work just fine on the new revision, it's just the tuner that does not work. I'm 100% certain that there is a live signal since I can use the same source successfully with a D1E9 and then move it to a D1F5 and see it fail. I've also tried both with a real TV signal and with a signal generator (so I could be 100% certain what signal was generated and at what frequency etc). I'm also fairly certain that it's not just a case of a random broken D1F5 since I have several and they all behave identically (and the driver doesn't complain about broken hardware). Here's what I get in dmesg when plugging one of the newer, non-working, devices into my laptop (running 2.6.39.3 by the way): [43171.480193] pvrusb2: Device being rendered inoperable [43173.195741] usb 1-1.1: new high speed USB device number 21 using ehci_hcd [43173.28] pvrusb2: Hardware description: WinTV HVR-1900 Model 73xxx [43173.321796] pvrusb2: Binding ir_rx_z8f0811_haup to i2c address 0x71. [43173.321817] pvrusb2: Binding ir_tx_z8f0811_haup to i2c address 0x70. [43173.325212] cx25840 18-0044: cx25843-24 found @ 0x88 (pvrusb2_a) [43173.335618] pvrusb2: Attached sub-driver cx25840 [43173.339439] tuner 18-0042: Tuner -1 found with type(s) Radio TV. [43173.339448] pvrusb2: Attached sub-driver tuner [43175.538224] cx25840 18-0044: loaded v4l-cx25840.fw firmware (16382 bytes) [43175.641103] tveeprom 18-00a2: Hauppauge model 73219, rev D1F5, serial# 6569758 [43175.641109] tveeprom 18-00a2: MAC address is 00:0d:fe:64:3f:1e [43175.641114] tveeprom 18-00a2: tuner model is NXP 18271C2 (idx 155, type 54) [43175.641119] tveeprom 18-00a2: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xf4) [43175.641124] tveeprom 18-00a2: audio processor is CX25843 (idx 37) [43175.641128] tveeprom 18-00a2: decoder processor is CX25843 (idx 30) [43175.641132] tveeprom 18-00a2: has radio, has IR receiver, has IR transmitter [43175.641142] pvrusb2: Supported video standard(s) reported available in hardware: PAL-B/B1/D/D1/G/H/I/K;SECAM-B/D/G/H/K/K [43175.641152] pvrusb2: Mapping standards mask=0x3ff00ff (PAL-B/B1/D/D1/G/H/I/K;SECAM-B/D/G/H/K/K1/L/LC;ATSC-8VSB/16VSB) [43175.641156] pvrusb2: Setting up 20 unique standard(s) [43175.641161] pvrusb2: Set up standard idx=0 name=PAL-B/G [43175.641165] pvrusb2: Set up standard idx=1 name=PAL-D/K [43175.641169] pvrusb2: Set up standard idx=2 name=SECAM-B/G [43175.641172] pvrusb2: Set up standard idx=3 name=SECAM-D/K [43175.641176] pvrusb2: Set up standard idx=4 name=PAL-B [43175.641179] pvrusb2: Set up standard idx=5 name=PAL-B1 [43175.641182] pvrusb2: Set up standard idx=6 name=PAL-G [43175.641185] pvrusb2: Set up standard idx=7 name=PAL-H [43175.641189] pvrusb2: Set up standard idx=8 name=PAL-I [43175.641192] pvrusb2: Set up standard idx=9 name=PAL-D [43175.641195] pvrusb2: Set up standard idx=10 name=PAL-D1 [43175.641198] pvrusb2: Set up standard idx=11 name=PAL-K [43175.641202] pvrusb2: Set up standard idx=12 name=SECAM-B [43175.641205] pvrusb2: Set up standard idx=13 name=SECAM-D [43175.641208] pvrusb2: Set up standard idx=14 name=SECAM-G [43175.641212] pvrusb2: Set up standard idx=15 name=SECAM-H [43175.641215] pvrusb2: Set up standard idx=16 name=SECAM-K [43175.641218] pvrusb2: Set up standard idx=17 name=SECAM-K1 [43175.641221] pvrusb2: Set up standard idx=18 name=SECAM-L [43175.641225] pvrusb2: Set up standard idx=19 name=SECAM-LC [43175.641228] pvrusb2: Initial video standard auto-selected to PAL-B/G [43175.641240] pvrusb2: Device initialization completed successfully. [43175.641361] pvrusb2: registered device video1 [mpeg] [43175.641365] DVB: registering new adapter (pvrusb2-dvb) [43177.891568] cx25840 18-0044: loaded v4l-cx25840.fw firmware (16382 bytes) [43178.010913] tda829x 18-0042: setting tuner address to 60 [43178.034089] tda18271 18-0060: creating new instance [43178.070613] TDA18271HD/C2 detected @ 18-0060 [43179.945888] tda18271: performing RF tracking filter calibration [43192.930384] tda18271: RF tracking filter calibration complete [43192.973646] tda829x 18-0042: type set to tda8295+18271 [43196.561274] cx25840 18-0044: 0x is not a valid video input! [43196.593146] DVB: registering adapter 0 frontend 0 (NXP TDA10048HN DVB-T)... [43196.594644] tda829x 18-0042: type set to tda8295 [43196.630097] tda18271 18-0060: attaching existing instance [43205.439659] cx25840 18-0044: loaded v4l-cx25840.fw firmware (16382 bytes) The only differences between this output and a working device is the revision number and the fact that the tuner is a TDA18271HD/C2 whereas
Re: Hauppauge model 73219 rev D1F5 tuner doesn't detect signal, older rev D1E9 works
On Tue, 19 Jul 2011, Michael Krufky wrote: On Tue, Jul 19, 2011 at 3:37 AM, Jesper Juhl j...@chaosbits.net wrote: ... I can test any patches you may come up with and if there's any further information you need from me in order to get an idea about what the problem is, then just ask. Please CC me on replies since I'm not subscribed to the linux-media list. -- Jesper Juhl j...@chaosbits.net http://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please. I have a suspicion as per the cause of this problem... Would you care to try a patch to see if it fixes the problem? (note: this should not be merged, as it is not an actual fix -- simply an test to show us how to arrive at the appropriate fix) Thank you Michael. I'll try this patch tomorrow when I have access to my test hardware. I'll get back to you with results ASAP. -- Jesper Juhl j...@chaosbits.net http://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please.
Re: [patch][saa7134] do not change mute state for capturing audio
19.07.2011 23:29, Mauro Carvalho Chehab wrote: the additional element, they are fine already. We can rename it to Master Capture Switch, or may not. Adding a new volume control that changes the mute values for the other controls or renaming it don't solve anything. The proposed solution is to have the mute control, that can be valid for all the cards/drivers. Presumably, it should have the similar name for all of them, even though for some it will be a virtual control that will control several items, and for others - it should map directly to their single mute control. If we have such a mute control, any app can use it, and the auto-unmute logic can be removed from the alsa driver. v4l2 is left as it is now. So that's the proposal, what problems can you see with it? So, am I right that the only problem is that it is not exported to the user by some _alsa_ drivers right now? I fail to see why this would be a problem. But that was the problem _you_ named. That is, that right now the app will have difficulties unmuting the complex boards via the alsa interface, because it will have to unmute several items instead of one. I propose to add the single item for that, except for the drivers that already have only one mute switch. With this, the problem you named, seems to be solved. And then, perhaps, the auto-unmute logic can go away. What am I missing? It is doable, although it is probably not trivial. Devices with saa7130 (PCI_DEVICE_ID_PHILIPS_SAA7130) doesn't enable the alsa module, as they don't support I2S transfers, required for PCM audio. So, we need to take care only on saa7133/4/5 devices. The mute code is at saa7134-tvaudio.c, mute_input_7134() function. For saa7134, it does: if (PCI_DEVICE_ID_PHILIPS_SAA7134 == dev-pci-device) /* 7134 mute */ saa_writeb(SAA7134_AUDIO_MUTE_CTRL, mute ? SAA7134_MUTE_MASK | SAA7134_MUTE_ANALOG | SAA7134_MUTE_I2S : SAA7134_MUTE_MASK); Clearly, there are two mute flags: SAA7134_MUTE_ANALOG and SAA7134_MUTE_I2S. I was actually already playing with that piece of code, and got no results. Will retry the next week-end to see exactly why... IIRC the problem was that this does not mute the sound input from the back panel of the board, which would then still go to the pass-through wire in case you are capturing. The only way do mute it, was to configure muxes the way you can't capture at the same time. But I may be wrong with the recollections. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] imon: don't parse scancodes until intf configured
On 20/07/11 02:12, Jarod Wilson wrote: The imon devices have either 1 or 2 usb interfaces on them, each wired up to its own urb callback. The interface 0 urb callback is wired up before the imon context's rc_dev pointer is filled in, which is necessary for imon 0xffdc device auto-detection to work properly, but we need to make sure we don't actually run the callback routines until we've entirely filled in the necessary bits for each given interface, lest we wind up oopsing. Technically, any imon device could have hit this, but the issue is exacerbated on the 0xffdc devices, which send a constant stream of interrupts, even when they have no valid key data. OK. The patch applies and everything continues to work. There is no obvious difference in the dmesg output on module load, with my device remaining unidentified. I don't know if that is indicative of anything. input: iMON Panel, Knob and Mouse(15c2:ffdc) as /devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/input/input9 imon 4-2:1.0: Unknown 0xffdc device, defaulting to VFD and iMON IR (id 0x00) Registered IR keymap rc-imon-pad input: iMON Remote (15c2:ffdc) as /devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/rc/rc3/input10 rc3: iMON Remote (15c2:ffdc) as /devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/rc/rc3 imon 4-2:1.0: iMON device (15c2:ffdc, intf0) on usb4:3 initialized usbcore: registered new interface driver imon intf0 decoded packet: 00 00 00 00 00 00 24 01 intf0 decoded packet: 00 00 00 00 00 00 24 01 intf0 decoded packet: 00 00 00 00 00 00 24 01 Regards, Chris -- Chris Williams Brisbane, Australia -- 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] add support for the dvb-t part of CT-3650 v3
On 07/19/2011 11:25 AM, Jose Alberto Reguero wrote:
On Martes, 19 de Julio de 2011 01:44:54 Antti Palosaari escribió:
On 07/19/2011 02:00 AM, Jose Alberto Reguero wrote:
On Lunes, 18 de Julio de 2011 22:28:41 Antti Palosaari escribió:
There are two problems:
First, the two frontends (tda10048 and tda10023) use tda10023 i2c gate
to talk with the tuner.
Very easy to implement correctly. Attach tda10023 first and after that
tda10048. Override tda10048 .i2c_gate_ctrl() with tda10023
.i2c_gate_ctrl() immediately after tda10048 attach inside ttusb2.c. Now
you have both demods (FEs) .i2c_gate_ctrl() which will control
physically tda10023 I2C-gate as tuner is behind it.
I try that, but don't work. I get an oops. Because the i2c gate function of
the tda10023 driver use:
struct tda10023_state* state = fe-demodulator_priv;
to get the i2c adress. When called from tda10048, don't work.
Jose Alberto
The second is that with dvb-usb, there is only one frontend, and if you
wake up the second frontend, the adapter is not wake up. That can be
avoided the way I do in the patch, or mantaining the adapter alwais on.
I think that could be also avoided similarly overriding demod callbacks
and adding some more logic inside ttusb2.c.
Proper fix that later problem is surely correct MFE support for
DVB-USB-framework. I am now looking for it, lets see how difficult it
will be.
Signed-off-by: Antti Palosaari cr...@iki.fi
Test attached patches and try to fix if they are not working. Most
likely not working since I don't have HW to test... I tested MFE parts
using Anysee, so it should be working. I changed rather much your ttusb2
and tda10048 patches, size reduced something like 50% or more. Still
ttusb2 I2C-adapter changes made looks rather complex. Try to double
check if those can be done easier. There is many drivers to look example
from.
DVB USB MFE is something like RFC. I know FE exclusive lock is missing,
no need to mention that :) But other comments are welcome! I left three
old unneeded pointers to struct dvb_usb_adapter to reduce changing all
the drivers.
regards
Antti
--
http://palosaari.fi/
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
b/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
index b3cb626..51c716f 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
@@ -162,8 +162,8 @@ static int dvb_usb_fe_wakeup(struct dvb_frontend *fe)
dvb_usb_device_power_ctrl(adap-dev, 1);
- if (adap-fe_init)
- adap-fe_init(fe);
+ if (adap-mfe_init[fe-id])
+ adap-mfe_init[fe-id](fe);
return 0;
}
@@ -172,35 +172,66 @@ static int dvb_usb_fe_sleep(struct dvb_frontend *fe)
{
struct dvb_usb_adapter *adap = fe-dvb-priv;
- if (adap-fe_sleep)
- adap-fe_sleep(fe);
+ if (adap-mfe_sleep[fe-id])
+ adap-mfe_sleep[fe-id](fe);
return dvb_usb_device_power_ctrl(adap-dev, 0);
}
int dvb_usb_adapter_frontend_init(struct dvb_usb_adapter *adap)
{
+ int ret, i, num_frontends;
+
if (adap-props.frontend_attach == NULL) {
- err(strange: '%s' #%d doesn't want to attach a
frontend.,adap-dev-desc-name, adap-id);
+ err(strange: '%s' #%d doesn't want to attach a frontend.,
+ adap-dev-desc-name, adap-id);
return 0;
}
- /* re-assign sleep and wakeup functions */
- if (adap-props.frontend_attach(adap) == 0 adap-fe != NULL) {
- adap-fe_init = adap-fe-ops.init; adap-fe-ops.init =
dvb_usb_fe_wakeup;
- adap-fe_sleep = adap-fe-ops.sleep; adap-fe-ops.sleep =
dvb_usb_fe_sleep;
+ if (adap-props.num_frontends)
+ num_frontends = adap-props.num_frontends;
+ else
+ num_frontends = 1;
+
+ for (i = 0; i num_frontends; i++) {
+
+ ret = adap-props.frontend_attach(adap);
+ if (ret)
+ break;
+
+ /* glue for backward compatibility */
+ if (i == 0) {
+ if (adap-mfe[i])
+ adap-fe = adap-mfe[i];
+ else
+ adap-mfe[i] = adap-fe;
+ }
+
+ if (adap-mfe[i] == NULL)
+ break;
+
+ /* re-assign sleep and wakeup functions */
+ adap-mfe_init[i] = adap-mfe[i]-ops.init;
+ adap-mfe_sleep[i] = adap-mfe[i]-ops.sleep;
+ adap-mfe[i]-ops.init = dvb_usb_fe_wakeup;
+ adap-mfe[i]-ops.sleep = dvb_usb_fe_sleep;
- if (dvb_register_frontend(adap-dvb_adap, adap-fe)) {
- err(Frontend registration failed.);
+ adap-mfe[i]-id = i;
+ if (dvb_register_frontend(adap-dvb_adap, adap-mfe[i])) {
+ err(Frontend %d registration failed., i);
Re: [patch][saa7134] do not change mute state for capturing audio
Em 19-07-2011 18:57, Stas Sergeev escreveu:
19.07.2011 23:29, Mauro Carvalho Chehab wrote:
the additional element, they are fine already.
We can rename it to Master Capture Switch,
or may not.
Adding a new volume control that changes the mute values for the other
controls
or renaming it don't solve anything.
The proposed solution is to have the mute
control, that can be valid for all the cards/drivers.
Presumably, it should have the similar name
for all of them, even though for some it will be
a virtual control that will control several items,
and for others - it should map directly to their
single mute control.
If we have such a mute control, any app can use
it,
Any app can do it right now via the V4L2 api.
and the auto-unmute logic can be removed
from the alsa driver. v4l2 is left as it is now.
What is the sense of capturing data for a device that is not ready
for stream? PA is doing the wrong thing here, due to the lack of a
better API support: it is starting stream on a device as a hacky way
of probing it. As Lennart pointed, even considering a pure audio device,
this is ugly and takes time.
IMO, the right long term fix is to provide alsa some ioctl that allows
PA to get the needed info without needing to start streaming, and, for
the short term, to prevent it to start capture on tuner/grabber devices.
So that's the proposal, what problems can you see
with it?
Userspace application breakage is not allowed. A change like
that will break the existing applications like mplayer.
So, am I right that the only problem is that it is not
exported to the user by some _alsa_ drivers right now?
I fail to see why this would be a problem.
But that was the problem _you_ named.
That is, that right now the app will have difficulties
unmuting the complex boards via the alsa interface,
because it will have to unmute several items instead
of one.
I propose to add the single item for that, except for
the drivers that already have only one mute switch.
With this, the problem you named, seems to be solved.
And then, perhaps, the auto-unmute logic can go away.
What am I missing?
It is doable, although it is probably not trivial.
Devices with saa7130 (PCI_DEVICE_ID_PHILIPS_SAA7130) doesn't enable the
alsa module, as they don't support I2S transfers, required for PCM audio.
So, we need to take care only on saa7133/4/5 devices.
The mute code is at saa7134-tvaudio.c, mute_input_7134() function. For
saa7134, it does:
if (PCI_DEVICE_ID_PHILIPS_SAA7134 == dev-pci-device)
/* 7134 mute */
saa_writeb(SAA7134_AUDIO_MUTE_CTRL, mute ?
SAA7134_MUTE_MASK |
SAA7134_MUTE_ANALOG |
SAA7134_MUTE_I2S :
SAA7134_MUTE_MASK);
Clearly, there are two mute flags: SAA7134_MUTE_ANALOG and SAA7134_MUTE_I2S.
I was actually already playing with that piece of
code, and got no results. Will retry the next week-end
to see exactly why...
Maybe your device is not a saa7134. For saa7133/saa7135, the
mute/unmute seems to be done via GPIO, and via amux.
IIRC the problem was that this does not mute the
sound input from the back panel of the board, which
would then still go to the pass-through wire in case
you are capturing. The only way do mute it, was to
configure muxes the way you can't capture at the
same time. But I may be wrong with the recollections.
Well, the change seems to be simple, as we don't actually need to
split the mute. We just need to control the I2S input/output at
the alsa driver.
The enclosed patch probably does the trick (completely untested).
As I said before, before adding this patch upstream, we need to double
check if it will work with saa7134, saa7133 and saa7135, preserving
the old behavior on those devices.
-
saa7134: Don't touch at the analog mute at the alsa driver
Instead of setting both analog and digital parts of the driver, alsa
just needs to enable/disable the I2S capture.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/saa7134/saa7134-alsa.c
b/drivers/media/video/saa7134/saa7134-alsa.c
index 10460fd..2edcdd2 100644
--- a/drivers/media/video/saa7134/saa7134-alsa.c
+++ b/drivers/media/video/saa7134/saa7134-alsa.c
@@ -720,7 +720,7 @@ static int snd_card_saa7134_capture_close(struct
snd_pcm_substream * substream)
if (saa7134-mute_was_on) {
dev-ctl_mute = 1;
- saa7134_tvaudio_setmute(dev);
+ saa7134_i2s_mute(dev, dev-ctl_mute);
}
return 0;
}
@@ -777,7 +777,7 @@ static int snd_card_saa7134_capture_open(struct
snd_pcm_substream * substream)
if (dev-ctl_mute != 0) {
saa7134-mute_was_on = 1;
dev-ctl_mute = 0;
- saa7134_tvaudio_setmute(dev);
+
Re: [RFCv1 PATCH 5/6] videobuf2-core: also test for pending events.
On Sun, Jul 17, 2011 at 23:30, Marek Szyprowski
m.szyprow...@samsung.com wrote:
Hello,
On Wednesday, July 13, 2011 11:39 AM Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Pawel Osciak pa...@osciak.com
---
drivers/media/video/videobuf2-core.c | 41 +++---
---
1 files changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 1892bb8..1922bf8 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -19,6 +19,9 @@
#include linux/slab.h
#include linux/sched.h
+#include media/v4l2-dev.h
+#include media/v4l2-fh.h
+#include media/v4l2-event.h
#include media/videobuf2-core.h
static int debug;
@@ -1360,15 +1363,28 @@ static int __vb2_cleanup_fileio(struct vb2_queue
*q);
* For OUTPUT queues, if a buffer is ready to be dequeued, the file
descriptor
* will be reported as available for writing.
*
+ * If the driver uses struct v4l2_fh, then vb2_poll() will also check for
any
+ * pending events.
+ *
* The return values from this function are intended to be directly
returned
* from poll handler in driver.
*/
unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table
*wait)
{
+ struct video_device *vfd = video_devdata(file);
unsigned long req_events = poll_requested_events(wait);
- unsigned long flags;
- unsigned int ret;
struct vb2_buffer *vb = NULL;
+ unsigned int res = 0;
+ unsigned long flags;
+
+ if (test_bit(V4L2_FL_USES_V4L2_FH, vfd-flags)) {
+ struct v4l2_fh *fh = file-private_data;
+
+ if (v4l2_event_pending(fh))
+ res = POLLPRI;
+ else if (req_events POLLPRI)
+ poll_wait(file, fh-wait, wait);
+ }
/*
* Start file I/O emulator only if streaming API has not been used
yet.
@@ -1376,19 +1392,17 @@ unsigned int vb2_poll(struct vb2_queue *q, struct
file *file, poll_table *wait)
if (q-num_buffers == 0 q-fileio == NULL) {
if (!V4L2_TYPE_IS_OUTPUT(q-type) (q-io_modes VB2_READ)
(req_events (POLLIN | POLLRDNORM))) {
- ret = __vb2_init_fileio(q, 1);
- if (ret)
- return POLLERR;
+ if (__vb2_init_fileio(q, 1))
+ return res | POLLERR;
}
if (V4L2_TYPE_IS_OUTPUT(q-type) (q-io_modes VB2_WRITE)
(req_events (POLLOUT | POLLWRNORM))) {
- ret = __vb2_init_fileio(q, 0);
- if (ret)
- return POLLERR;
+ if (__vb2_init_fileio(q, 0))
+ return res | POLLERR;
/*
* Write to OUTPUT queue can be done immediately.
*/
- return POLLOUT | POLLWRNORM;
+ return res | POLLOUT | POLLWRNORM;
}
}
@@ -1396,7 +1410,7 @@ unsigned int vb2_poll(struct vb2_queue *q, struct
file *file, poll_table *wait)
* There is nothing to wait for if no buffers have already been
queued.
*/
if (list_empty(q-queued_list))
- return POLLERR;
+ return res | POLLERR;
poll_wait(file, q-done_wq, wait);
@@ -1411,10 +1425,11 @@ unsigned int vb2_poll(struct vb2_queue *q, struct
file *file, poll_table *wait)
if (vb (vb-state == VB2_BUF_STATE_DONE
|| vb-state == VB2_BUF_STATE_ERROR)) {
- return (V4L2_TYPE_IS_OUTPUT(q-type)) ? POLLOUT | POLLWRNORM :
- POLLIN | POLLRDNORM;
+ return (V4L2_TYPE_IS_OUTPUT(q-type)) ?
+ res | POLLOUT | POLLWRNORM :
+ res | POLLIN | POLLRDNORM;
}
- return 0;
+ return res;
}
EXPORT_SYMBOL_GPL(vb2_poll);
--
Best regards
--
Marek Szyprowski
Samsung Poland RD Center
--
Best regards,
Pawel Osciak
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1 PATCH 3/6] videobuf2: only start streaming in poll() if so requested by the poll mask.
Hi Hans,
On Sun, Jul 17, 2011 at 23:30, Marek Szyprowski
m.szyprow...@samsung.com wrote:
Hello,
On Wednesday, July 13, 2011 11:39 AM Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Pawel Osciak pa...@osciak.com
I have to say, this is cool stuff!
Pawel
---
drivers/media/video/videobuf2-core.c | 7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 3015e60..1892bb8 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -1365,6 +1365,7 @@ static int __vb2_cleanup_fileio(struct vb2_queue *q);
*/
unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table
*wait)
{
+ unsigned long req_events = poll_requested_events(wait);
unsigned long flags;
unsigned int ret;
struct vb2_buffer *vb = NULL;
@@ -1373,12 +1374,14 @@ unsigned int vb2_poll(struct vb2_queue *q, struct
file *file, poll_table *wait)
* Start file I/O emulator only if streaming API has not been used
yet.
*/
if (q-num_buffers == 0 q-fileio == NULL) {
- if (!V4L2_TYPE_IS_OUTPUT(q-type) (q-io_modes VB2_READ))
{
+ if (!V4L2_TYPE_IS_OUTPUT(q-type) (q-io_modes VB2_READ)
+ (req_events (POLLIN | POLLRDNORM))) {
ret = __vb2_init_fileio(q, 1);
if (ret)
return POLLERR;
}
- if (V4L2_TYPE_IS_OUTPUT(q-type) (q-io_modes VB2_WRITE))
{
+ if (V4L2_TYPE_IS_OUTPUT(q-type) (q-io_modes VB2_WRITE)
+ (req_events (POLLOUT | POLLWRNORM))) {
ret = __vb2_init_fileio(q, 0);
if (ret)
return POLLERR;
--
Best regards
--
Marek Szyprowski
Samsung Poland RD Center
--
Best regards,
Pawel Osciak
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vb2: Push buffer allocation and freeing into drivers
Hi Jon, Thanks for your patch. I agree I'm not particularly proud of how allocation looks like right now and of the first structure field requirement. I had similar design dilemmas, but have to agree with Marek here though. Please see my explanation below. On Mon, Jun 27, 2011 at 09:39, Jonathan Corbet cor...@lwn.net wrote: On Mon, 27 Jun 2011 18:09:41 +0200 Marek Szyprowski m.szyprow...@samsung.com wrote: Thanks for your work! I really appreciate your effort for making the kernel code better. :) However I would like to get some more comments before making the final decision. That's fine - it *was* an RFC, after all...:) The main difference between buffer_init() and buffer_alloc() is the fact that buffer_init() is called when the buffer has all internal data filled in (like for example index) and, what is more important, memory buffers for all planes are already allocated. I had thought that might be the case, but none of the in-tree drivers needed that information. Obviously, I don't want to break other stuff which is coming (that driver *is* headed for mainline, right? :), so the idea of simply repurposing buf_init() won't quite work. Too bad, moving it took out a lot of error-handling code. One thing that I think wasn't mentioned was that you did remove buf_init call from __qbuf_userptr(), which removes some functionality and symmetry. In USERPTR case we still want to call buf_init(), as it's used to perform operations that are to be done once per buffer, after it is ready. There is no allocation in USERPTR's case though. So it's not as much a feature for particular drivers, but to accommodate USERPTR. For MMAP, we could do those things in buf_alloc(). Could this more involved initialization code move to buf_prepare(), perhaps with a flag in the buffer for stuff that only has to happen once? Or maybe there could be a highly optional buf_map() (or some such) for this kind of special-case driver? buf_prepare() is called once per frame, so checking for this flag every frame would add some unpleasant overhead. I considered similar solution during videobuf2 development, but decided that having access to all information about buffer internals (index, plane addresses) is something that might be really useful for device drivers. I guess the question is: is it sufficiently useful to enough drivers to create a separate callback for? I'm not convinced...but I could certainly be wrong about that. You mean buf_init(), right? Well, I aimed for this nice symmetry: buf_init() - buf_cleanup() buf_prepare() - buf_finish() I agree many drivers might not need such fine-grained design, but as we could find sensible use cases for all of them, all of them were kept. Creating additional buffer_alloc() and buffer_free() callbacks (and keeping buffer_init and buffer_cleanup) just to make the code nicer was already pointed to be just an over-engineering. I don't think there's a need for a buf_free(), given that buf_cleanup() is already there. But I really dislike the vb2_buffer must be the first structure field requirement; it's fragile in the long term. The kernel has usually gone out of its way to avoid adding that kind of hidden constraint. As with buf_init() and allocation, you don't always free the memory when you buf_cleanup(), which happens in USERPTR case. Oh, well. I'd like to see the change merged, I think it makes things a little better. But I've said my piece now and don't intend to argue it further - I'll keep using vb2 either way :) Thanks, jon -- Best regards, Pawel Osciak -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l: remove single to multiplane conversion
On Wed, Jul 6, 2011 at 02:23, Tomasz Stanislawski
t.stanisl...@samsung.com wrote:
This patch removes an implicit conversion between multi and single plane
formats from V4L2 framework. The conversion is to be performed by libv4l2.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Acked-by: Pawel Osciak pa...@osciak.com
drivers/media/video/v4l2-ioctl.c | 250
++
1 files changed, 12 insertions(+), 238 deletions(-)
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index 213ba7d..07f2abd 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -476,63 +476,6 @@ static int check_fmt(const struct v4l2_ioctl_ops *ops,
enum v4l2_buf_type type)
return -EINVAL;
}
-/**
- * fmt_sp_to_mp() - Convert a single-plane format to its multi-planar 1-plane
- * equivalent
- */
-static int fmt_sp_to_mp(const struct v4l2_format *f_sp,
- struct v4l2_format *f_mp)
-{
- struct v4l2_pix_format_mplane *pix_mp = f_mp-fmt.pix_mp;
- const struct v4l2_pix_format *pix = f_sp-fmt.pix;
-
- if (f_sp-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
- f_mp-type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
- else if (f_sp-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
- f_mp-type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
- else
- return -EINVAL;
-
- pix_mp-width = pix-width;
- pix_mp-height = pix-height;
- pix_mp-pixelformat = pix-pixelformat;
- pix_mp-field = pix-field;
- pix_mp-colorspace = pix-colorspace;
- pix_mp-num_planes = 1;
- pix_mp-plane_fmt[0].sizeimage = pix-sizeimage;
- pix_mp-plane_fmt[0].bytesperline = pix-bytesperline;
-
- return 0;
-}
-
-/**
- * fmt_mp_to_sp() - Convert a multi-planar 1-plane format to its
single-planar
- * equivalent
- */
-static int fmt_mp_to_sp(const struct v4l2_format *f_mp,
- struct v4l2_format *f_sp)
-{
- const struct v4l2_pix_format_mplane *pix_mp = f_mp-fmt.pix_mp;
- struct v4l2_pix_format *pix = f_sp-fmt.pix;
-
- if (f_mp-type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
- f_sp-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
- else if (f_mp-type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
- f_sp-type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
- else
- return -EINVAL;
-
- pix-width = pix_mp-width;
- pix-height = pix_mp-height;
- pix-pixelformat = pix_mp-pixelformat;
- pix-field = pix_mp-field;
- pix-colorspace = pix_mp-colorspace;
- pix-sizeimage = pix_mp-plane_fmt[0].sizeimage;
- pix-bytesperline = pix_mp-plane_fmt[0].bytesperline;
-
- return 0;
-}
-
static long __video_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
{
@@ -540,7 +483,6 @@ static long __video_do_ioctl(struct file *file,
const struct v4l2_ioctl_ops *ops = vfd-ioctl_ops;
void *fh = file-private_data;
struct v4l2_fh *vfh = NULL;
- struct v4l2_format f_copy;
int use_fh_prio = 0;
long ret = -EINVAL;
@@ -702,42 +644,15 @@ static long __video_do_ioctl(struct file *file,
switch (f-type) {
case V4L2_BUF_TYPE_VIDEO_CAPTURE:
- if (ops-vidioc_g_fmt_vid_cap) {
+ if (ops-vidioc_g_fmt_vid_cap)
ret = ops-vidioc_g_fmt_vid_cap(file, fh, f);
- } else if (ops-vidioc_g_fmt_vid_cap_mplane) {
- if (fmt_sp_to_mp(f, f_copy))
- break;
- ret = ops-vidioc_g_fmt_vid_cap_mplane(file,
fh,
-
f_copy);
- if (ret)
- break;
-
- /* Driver is currently in multi-planar format,
- * we can't return it in single-planar API*/
- if (f_copy.fmt.pix_mp.num_planes 1) {
- ret = -EBUSY;
- break;
- }
-
- ret = fmt_mp_to_sp(f_copy, f);
- }
if (!ret)
v4l_print_pix_fmt(vfd, f-fmt.pix);
break;
case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
- if (ops-vidioc_g_fmt_vid_cap_mplane) {
+ if (ops-vidioc_g_fmt_vid_cap_mplane)
ret = ops-vidioc_g_fmt_vid_cap_mplane(file,
fh, f);
-
Re: [patch][saa7134] do not change mute state for capturing audio
20.07.2011 04:55, Mauro Carvalho Chehab wrote: The proposed solution is to have the mute control, that can be valid for all the cards/drivers. Presumably, it should have the similar name for all of them, even though for some it will be a virtual control that will control several items, and for others - it should map directly to their single mute control. If we have such a mute control, any app can use it, Any app can do it right now via the V4L2 api. I am just following your logic, you said that --- Moving such logic to happen at userspace would be very complex, and will break existing applications. --- To solve that, I proposed adding such mixer control to where it is missing right now. But if this is no longer a problem and the app can just use v4l2 for that instead, then what still keeps us from removing the auto-unmute things? and the auto-unmute logic can be removed from the alsa driver. v4l2 is left as it is now. What is the sense of capturing data for a device that is not ready for stream? This may be a PA's hack, or a user's mistake, or whatever, but whatever it is, it shouldn't lead to any sounds from speakers. Just starting the capture, willingly or by mistake, should never lead to any sound from speakers, IMO. So that's the bug too. And the simpler one to fix. So that's the proposal, what problems can you see with it? Userspace application breakage is not allowed. A change like that will break the existing applications like mplayer. No, because, as you said, it uses v4l2, not alsa, to unmute. And my proposal only affects alsa, so what's the breakage? Maybe your device is not a saa7134. For saa7133/saa7135, the mute/unmute seems to be done via GPIO, and via amux. Yes, and that's exacly why unmuting only I2S does nothing: the muxes are still set up for mute. IIRC the problem was that this does not mute the sound input from the back panel of the board, which would then still go to the pass-through wire in case you are capturing. The only way do mute it, was to configure muxes the way you can't capture at the same time. But I may be wrong with the recollections. Well, the change seems to be simple, as we don't actually need to split the mute. We just need to control the I2S input/output at the alsa driver. The enclosed patch probably does the trick (completely untested). I'll be able to test it on avertv 307 the next week-end. But what is the expected effect of that patch? It looks much like mine: mostly just removes auto-unmute, doing that in a not-so-obvious way. The card is muted by setting up the muxes. Now you unmute it by enabling I2S, but the muxes are still set to mute, so nothing happens, and you will capture the silence. I think this patch is _correct_, as it removes the auto-unmute logic; exactly what I proposed. :) Just a slightly different implementation, unless I am missing something obvious... By the way, do you need to do saa7134_i2s_mute(dev, mute); from mute_input_7134() ? Maybe leaving that I2S control entirely for alsa, and not touching it elsewhere? The function itself can probably then be moved to saa7134-alsa.c. Thanks! -- 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
