Re: [RFCv5 3/9] mm: cma: Added SysFS support
On Tue, Sep 07, 2010 at 07:31:30AM +0200, Micha?? Nazarewicz wrote:
Hello Greg,
Thanks for reviewing the sysfs part. Actually, I was never really sure
if I shouldn't rather put this code to debugfs and you got me convinced
that I should. Sysfs somehow looked more appealing from kernel's API
point of view -- things seem to be more organised in sysfs than in
debugfs. It seems I'll have to port it to debugfs after all
Yes, debugfs looks like a much better place for this. You can do
whatever you want in debugfs as long as you follow the one rule for it:
There are no rules for debugfs.
Nonetheless, a few responses to your comments:
On Mon, Sep 06, 2010 at 08:33:53AM +0200, Michal Nazarewicz wrote:
+ The allocators file list all registered allocators.
+ Allocators with no name are listed as a single minus
+ sign.
On Mon, 06 Sep 2010 23:07:47 +0200, Greg KH g...@kroah.com wrote:
So this returns more than one value?
Aren't thing like cpufreq governors listed in a single sysfs file?
Yeah, but I don't like it :)
I remember there was such a file somewhere. Has that been made
deprecated? I cannot seem to find any information on that.
It's best if you really don't do this, but it does happen as it is the
best way to show the information. If that's the case, fine.
+ The regions directory list all reserved regions.
Same here?
regions is actually a directory with subdirectories for each
region. ;)
Ah.
+static ssize_t cma_sysfs_region_name_show(struct cma_region *reg, char
*page)
+{
+ return reg-name ? snprintf(page, PAGE_SIZE, %s\n, reg-name) : 0;
+}
Is a name field ever really going to be bigger than a page?
I prefer being on the safe side -- I have no idea what user will provide
as region name so I assume as little as possible.
By user do you mean userspace, or another kernel driver file? If it's
a kernel driver, you can assume that they will be sane. if userspace,
assume it's insane and do some checking of the name before you use it.
For numeric values you are right that snprintf() is a bit paranoid,
still I see no good reason why not to use it.
Same goes for no good reason to use it :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv5 3/9] mm: cma: Added SysFS support
On Tue, Sep 07, 2010 at 07:31:30AM +0200, Micha?? Nazarewicz wrote:
Thanks for reviewing the sysfs part. Actually, I was never really sure
if I shouldn't rather put this code to debugfs and you got me convinced
that I should. Sysfs somehow looked more appealing from kernel's API
point of view -- things seem to be more organised in sysfs than in
debugfs. It seems I'll have to port it to debugfs after all
On Tue, 07 Sep 2010 08:08:18 +0200, Greg KH g...@kroah.com wrote:
Yes, debugfs looks like a much better place for this.
I'll fix that in v6 then.
+static ssize_t cma_sysfs_region_name_show(struct cma_region *reg, char *page)
+{
+ return reg-name ? snprintf(page, PAGE_SIZE, %s\n, reg-name) : 0;
+}
Is a name field ever really going to be bigger than a page?
For numeric values you are right that snprintf() is a bit paranoid,
still I see no good reason why not to use it.
Same goes for no good reason to use it :)
I somehow prefer to always use safe versions of the string manipulation
functions -- it's better to use it everywhere then to forget it in one
place. Call to sprintf() is translated to vsnprintf() anyway so there's
no performance gain.
--
Best regards,_ _
| Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o
| Computer Science, Michał mina86 Nazarewicz (o o)
+[mina86*mina86.com]---[mina86*jabber.org]ooO--(_)--Ooo--
--
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] Illuminators and status LED controls
Hi,
Looks good to me.
Acked-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
On 09/06/2010 08:11 PM, Jean-Francois Moine wrote:
Hi,
This new proposal cancels the previous 'LED control' patch.
Cheers.
-- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
led.patch
Some media devices (microscopes) may have one or many illuminators,
and most webcams have a status LED which is normally on when capture is active.
This patch makes them controlable by the applications.
Signed-off-by: Jean-Francois Moinemoin...@free.fr
diff --git a/Documentation/DocBook/v4l/controls.xml
b/Documentation/DocBook/v4l/controls.xml
index 8408caa..77f87ad 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -312,10 +312,27 @@ minimum value disables backlight compensation./entry
information and bits 24-31 must be zero./entry
/row
row
+ entryconstantV4L2_CID_ILLUMINATORS/constant/entry
+ entryinteger/entry
+ entrySwitch on or off the illuminator(s) of the device
+ (usually a microscope).
+ The control type and values depend on the driver and may be either
+ a single boolean (0: off, 1:on) or defined by a menu type./entry
+ /row
+ row id=v4l2_status_led
+ entryconstantV4L2_CID_STATUS_LED/constant/entry
+ entryinteger/entry
+ entrySet the status LED behaviour. Possible values for
+constantenum v4l2_status_led/constant are:
+constantV4L2_STATUS_LED_AUTO/constant (0),
+constantV4L2_STATUS_LED_ON/constant (1),
+constantV4L2_STATUS_LED_OFF/constant (2)./entry
+ /row
+ row
entryconstantV4L2_CID_LASTP1/constant/entry
entry/entry
entryEnd of the predefined control IDs (currently
-constantV4L2_CID_BG_COLOR/constant + 1)./entry
+constantV4L2_CID_STATUS_LED/constant + 1)./entry
/row
row
entryconstantV4L2_CID_PRIVATE_BASE/constant/entry
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 61490c6..75e8869 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1045,8 +1045,16 @@ enum v4l2_colorfx {
#define V4L2_CID_CHROMA_GAIN(V4L2_CID_BASE+36)
+#define V4L2_CID_ILLUMINATORS (V4L2_CID_BASE+37)
+#define V4L2_CID_STATUS_LED(V4L2_CID_BASE+38)
+enum v4l2_status_led {
+ V4L2_STATUS_LED_AUTO= 0,
+ V4L2_STATUS_LED_ON = 1,
+ V4L2_STATUS_LED_OFF = 2,
+};
+
/* last CID + 1 */
-#define V4L2_CID_LASTP1 (V4L2_CID_BASE+37)
+#define V4L2_CID_LASTP1 (V4L2_CID_BASE+39)
/* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE(V4L2_CTRL_CLASS_MPEG | 0x900)
--
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] Illuminators and status LED controls
On Monday, September 06, 2010 20:11:05 Jean-Francois Moine wrote: Hi, This new proposal cancels the previous 'LED control' patch. Cheers. Hi Jean-Francois, You must also add support for these new controls in v4l2-ctrls.c in v4l2_ctrl_get_menu(), v4l2_ctrl_get_name() and v4l2_ctrl_fill(). How is CID_ILLUMINATORS supposed to work in the case of multiple lights? Wouldn't a bitmask type be more suitable to this than a menu type? There isn't a bitmask type at the moment, but this seems to be a pretty good candidate for a type like that. Actually, for the status led I would also use a bitmask since there may be multiple leds. I guess you would need two bitmasks: one to select auto vs manual, and one for the manual settings. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Help needed
On 7 September 2010 07:33, Jimmy Öhlin jimmy.oh...@artvise.se wrote: Hello, Hope that you can help me with the following questions. I need a dvb-t and dvb-s2 card that work with Common Interface (Swedish Boxer and Canal Digital). I have looked at different dvb cards but… still not found a DVB-T and DVB-S2 card that will work under linux with CI support. I will use mplayer with ca_zap as frontend for my dvb application. Kind Regards, Jimmy Ohlin ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Are you saying you need a single card with both interfaces? Are you happy being able to record on only DVB-T or DVB-S2 one at a time? -- 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 WinTV-NOVA-T-500 support
Hello, According to the wiki entry for the Hauppauge WinTV-NOVA-T-500 hardware: http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-T-500 Models 289 and 287 are supported (ie: the UK sold cards), but model 283 sold in Germany, Switzerland and maybe some other countries isn't. Is this still an accurate statement or has this situation evolved but hasn't been updated in the wiki entry? Regards, Thomas -- 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
DVB-T, TV scan not successful: Cinergy Hybrid T USB XS
Hello! After the new installation of openSuSE 11.3 (kernel 2.6.34-12-desktop) I tried to install my Cinergy Hybrid T USB XS. This stick already worked under openSuSE 10.3. If I start the Kaffeine scan for TV channels following happens (roughly): Signal/SNR/Tuned: 60%/31%/light green, 0% ... Singal/SNR/Tuned: 60%/73%/green, 11 % Signal/SNR/Tuned: 100%/0%/green, 11% ... 100% While SNR 73% scan made some weird wrong entries in column Scan Results. I do not know what I am doing wrong. I hope so much that anybody can help. Some system data and collected information: v kaffeine-1.0-25.1.x86_64 kaffeine-lang-1.0-1.pm.2.1.noarch kdebase4-runtime-xine-4.4.4-2.4.x86_64, ... vdr-plugin-xine-0.9.3-7.2.x86_64 kdebase4-runtime-4.4.4-2.4.x86_64, ... - kaffeine, configure TV: device 1: Zarlink ZL10353 DVB-T -- invoking kaffeine with: kaffeine --dumpdvb: (while scanning for channels) kaffeine(14378) DvbScanFilter::timerEvent: timeout while reading section; type = 2 pid = 17 kaffeine(14378) DvbScanFilter::timerEvent: timeout while reading section; type = 1 pid = 240 kaffeine(14378) DvbScanFilter::timerEvent: timeout while reading section; type = 0 pid = 0 kaffeine(14378) DvbScanFilter::timerEvent: timeout while reading section; type = 2 pid = 17 kaffeine(14378) DvbScanFilter::timerEvent: timeout while reading section; type = 4 pid = 16 kaffeine(14378) DvbDevice::frontendEvent: tuning failed kaffeine(14378) DvbDevice::frontendEvent: tuning failed kaffeine(14378) DvbDevice::frontendEvent: tuning failed kaffeine(14378) DvbDevice::frontendEvent: tuning failed kaffeine(14378) DvbDevice::frontendEvent: tuning failed kaffeine(14378) DvbDevice::frontendEvent: tuning failed kaffeine(14378) DvbDevice::frontendEvent: tuning failed dmesg: [ 17.299642] em28xx: New device TerraTec Electronic GmbH Cinergy Hybrid T USB XS (2882) @ 480 Mbps (0ccd:005e, interface 0, class 0) [ 17.299757] em28xx #0: chip ID is em2882/em2883 ... [ 17.344047] VIA 82xx Audio :00:11.5: PCI INT C - GSI 22 (level, low) - IRQ 22 [ 17.344235] VIA 82xx Audio :00:11.5: setting latency timer to 64 ... [ 17.458267] em28xx #0: i2c eeprom 00: 1a eb 67 95 cd 0c 5e 00 d0 12 5c 03 9e 40 de 1c [ 17.458284] em28xx #0: i2c eeprom 10: 6a 34 27 57 46 07 01 00 00 00 00 00 00 00 00 00 [ 17.458297] em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 31 00 b8 00 14 00 5b 1e 00 00 [ 17.458309] em28xx #0: i2c eeprom 30: 00 00 20 40 20 6e 02 20 10 01 00 00 00 00 00 00 [ 17.458321] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 17.458332] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 17.458343] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 34 03 54 00 65 00 [ 17.458355] em28xx #0: i2c eeprom 70: 72 00 72 00 61 00 54 00 65 00 63 00 20 00 45 00 [ 17.458366] em28xx #0: i2c eeprom 80: 6c 00 65 00 63 00 74 00 72 00 6f 00 6e 00 69 00 [ 17.458378] em28xx #0: i2c eeprom 90: 63 00 20 00 47 00 6d 00 62 00 48 00 00 00 40 03 [ 17.458390] em28xx #0: i2c eeprom a0: 43 00 69 00 6e 00 65 00 72 00 67 00 79 00 20 00 [ 17.458401] em28xx #0: i2c eeprom b0: 48 00 79 00 62 00 72 00 69 00 64 00 20 00 54 00 [ 17.458413] em28xx #0: i2c eeprom c0: 20 00 55 00 53 00 42 00 20 00 58 00 53 00 20 00 [ 17.458424] em28xx #0: i2c eeprom d0: 28 00 32 00 38 00 38 00 32 00 29 00 00 00 1c 03 [ 17.458436] em28xx #0: i2c eeprom e0: 30 00 37 00 30 00 39 00 30 00 32 00 30 00 30 00 [ 17.458447] em28xx #0: i2c eeprom f0: 31 00 36 00 30 00 32 00 00 00 00 00 00 00 00 00 [ 17.458460] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xb213b0be [ 17.458463] em28xx #0: EEPROM info: [ 17.458465] em28xx #0: AC97 audio (5 sample rates) [ 17.458467] em28xx #0: 500mA max power [ 17.458469] em28xx #0: Table at 0x27, strings=0x409e, 0x1cde, 0x346a [ 17.459515] em28xx #0: Identified as Terratec Hybrid XS (em2882) (card=55) [ 17.779888] tvp5150 1-005c: chip found @ 0xb8 (em28xx #0) [ 18.030350] tuner 1-0061: chip found @ 0xc2 (em28xx #0) [ 18.077720] xc2028 1-0061: creating new instance [ 18.077725] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner [ 18.077734] usb 1-3: firmware: requesting xc3028-v27.fw [ 18.080251] xc2028 1-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 [ 18.115013] xc2028 1-0061: Loading firmware for type=BASE MTS (5), id . [ 19.018857] xc2028 1-0061: Loading firmware for type=MTS (4), id b700. [ 19.034231] xc2028 1-0061: Loading SCODE for type=MTS LCD NOGD MONO IF SCODE HAS_IF_4500 (6002b004), id b700. [ 19.197366] input: em28xx IR (em28xx #0) as /devices/pci:00/:00:10.4/usb1/1-3/input/input5 [ 19.197552] Creating IR device irrcv0 [ 19.197867] em28xx #0: Config register raw data: 0xd0 [ 19.199035] em28xx #0: AC97 vendor ID = 0x [ 19.199397] em28xx #0: AC97 features = 0x6a90 [ 19.199402] em28xx #0: Empia 202 AC97 audio
[GIT PATCHES FOR 2.6.37] davinci videobuf fixes
Hi Mauro, The following changes since commit 50b9d21ae2ac1b85be46f1ee5aa1b5e588622361: Jarod Wilson (1): V4L/DVB: mceusb: add two new ASUS device IDs are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git for-2.6.37 Hans Verkuil (1): videobuf-dma-sg: set correct size in last sg element Mats Randgaard (4): videobuf-core.c: Replaced BUG_ON with WARN_ON vpif_cap/disp: Removed section mismatch warning vpif_cap/disp: Replaced kmalloc with kzalloc vpif_cap/disp: Fixed strlcpy NULL pointer bug This patch series prepares for a future patch series that adds HDTV support to the davinci drivers. We (Tandberg) have those patches ready, but it needs more testing before we post them. Regarding the two videobuf patches: the dma-sg patch fixes a nasty memory corruption bug that took me several days to track down. It might be a candidate for 2.6.36 as well, but this bug has been there for ages and apparently nobody noticed, so I decided to do this for 2.6.37 only. The other videobuf patch changes a completely unnecessary BUG_ON to a WARN_ON. Regards, Hans drivers/media/video/davinci/vpif_capture.c |9 + drivers/media/video/davinci/vpif_display.c | 11 ++- drivers/media/video/videobuf-core.c|2 +- drivers/media/video/videobuf-dma-sg.c | 11 +++ include/media/videobuf-dma-sg.h|1 + 5 files changed, 20 insertions(+), 14 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Illuminators and status LED controls
Hi, On 09/07/2010 09:30 AM, Hans Verkuil wrote: On Monday, September 06, 2010 20:11:05 Jean-Francois Moine wrote: Hi, This new proposal cancels the previous 'LED control' patch. Cheers. Hi Jean-Francois, You must also add support for these new controls in v4l2-ctrls.c in v4l2_ctrl_get_menu(), v4l2_ctrl_get_name() and v4l2_ctrl_fill(). How is CID_ILLUMINATORS supposed to work in the case of multiple lights? Wouldn't a bitmask type be more suitable to this than a menu type? There isn't a bitmask type at the moment, but this seems to be a pretty good candidate for a type like that. Actually, for the status led I would also use a bitmask since there may be multiple leds. I guess you would need two bitmasks: one to select auto vs manual, and one for the manual settings. So far I've not seen cameras with multiple status leds, I do have seen camera which have the following settings for their 1 led (logitech uvc cams): auto on off blinking So I think a menu type is better suited, and that is what the current (private) uvc control uses. 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] Illuminators and status LED controls
Replying to myself. On 09/07/2010 11:42 AM, Hans de Goede wrote: Hi, On 09/07/2010 09:30 AM, Hans Verkuil wrote: On Monday, September 06, 2010 20:11:05 Jean-Francois Moine wrote: Hi, This new proposal cancels the previous 'LED control' patch. Cheers. Hi Jean-Francois, You must also add support for these new controls in v4l2-ctrls.c in v4l2_ctrl_get_menu(), v4l2_ctrl_get_name() and v4l2_ctrl_fill(). How is CID_ILLUMINATORS supposed to work in the case of multiple lights? Wouldn't a bitmask type be more suitable to this than a menu type? There isn't a bitmask type at the moment, but this seems to be a pretty good candidate for a type like that. Actually, for the status led I would also use a bitmask since there may be multiple leds. I guess you would need two bitmasks: one to select auto vs manual, and one for the manual settings. So far I've not seen cameras with multiple status leds, I do have seen camera which have the following settings for their 1 led (logitech uvc cams): auto on off blinking So I think a menu type is better suited, and that is what the current (private) uvc control uses. The same argument more or less goes for the CID_ILLIMUNATORS controls. Also given that we currently don't have a bitmask type I think introducing one without a really really good reason is a bad idea as any exiting apps won't know how to deal with it. 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] Illuminators and status LED controls
On Tuesday, September 07, 2010 11:44:18 Hans de Goede wrote: Replying to myself. On 09/07/2010 11:42 AM, Hans de Goede wrote: Hi, On 09/07/2010 09:30 AM, Hans Verkuil wrote: On Monday, September 06, 2010 20:11:05 Jean-Francois Moine wrote: Hi, This new proposal cancels the previous 'LED control' patch. Cheers. Hi Jean-Francois, You must also add support for these new controls in v4l2-ctrls.c in v4l2_ctrl_get_menu(), v4l2_ctrl_get_name() and v4l2_ctrl_fill(). How is CID_ILLUMINATORS supposed to work in the case of multiple lights? Wouldn't a bitmask type be more suitable to this than a menu type? There isn't a bitmask type at the moment, but this seems to be a pretty good candidate for a type like that. Actually, for the status led I would also use a bitmask since there may be multiple leds. I guess you would need two bitmasks: one to select auto vs manual, and one for the manual settings. So far I've not seen cameras with multiple status leds, I do have seen camera which have the following settings for their 1 led (logitech uvc cams): auto on off blinking So I think a menu type is better suited, and that is what the current (private) uvc control uses. The same argument more or less goes for the CID_ILLIMUNATORS controls. Also given that we currently don't have a bitmask type I think introducing one without a really really good reason is a bad idea as any exiting apps won't know how to deal with it. But I can guarantee that we will get video devices with multiple leds in the future. So we need to think *now* about how to do this. One simple option is of course to name the controls CID_ILLUMINATOR0 and CID_LED0. That way we can easily add LED1, LED2, etc. later without running into weird inconsistent control names. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Illuminators and status LED controls
Hi all, On 09/07/2010 11:47 AM, Hans Verkuil wrote: On Tuesday, September 07, 2010 11:44:18 Hans de Goede wrote: Replying to myself. On 09/07/2010 11:42 AM, Hans de Goede wrote: Hi, On 09/07/2010 09:30 AM, Hans Verkuil wrote: On Monday, September 06, 2010 20:11:05 Jean-Francois Moine wrote: Hi, This new proposal cancels the previous 'LED control' patch. Cheers. Hi Jean-Francois, You must also add support for these new controls in v4l2-ctrls.c in v4l2_ctrl_get_menu(), v4l2_ctrl_get_name() and v4l2_ctrl_fill(). How is CID_ILLUMINATORS supposed to work in the case of multiple lights? Wouldn't a bitmask type be more suitable to this than a menu type? There isn't a bitmask type at the moment, but this seems to be a pretty good candidate for a type like that. Actually, for the status led I would also use a bitmask since there may be multiple leds. I guess you would need two bitmasks: one to select auto vs manual, and one for the manual settings. So far I've not seen cameras with multiple status leds, I do have seen camera which have the following settings for their 1 led (logitech uvc cams): auto on off blinking So I think a menu type is better suited, and that is what the current (private) uvc control uses. The same argument more or less goes for the CID_ILLIMUNATORS controls. Also given that we currently don't have a bitmask type I think introducing one without a really really good reason is a bad idea as any exiting apps won't know how to deal with it. But I can guarantee that we will get video devices with multiple leds in the future. So we need to think *now* about how to do this. One simple option is of course to name the controls CID_ILLUMINATOR0 and CID_LED0. That way we can easily add LED1, LED2, etc. later without running into weird inconsistent control names. Naming them LED0 and ILLUMINATOR0 works for me. Note about the illuminator one, if you look at the patch it made the illuminator control a menu with the following options: Both off Top on, Bottom off Top off, Bottom on Both on Which raises the question do we leave this as is, or do we make this 2 boolean controls. I personally would like to vote for keeping it as is, as both lamps illuminate the same substrate in this case, and esp. switching between Top on, Bottom off to Top off, Bottom on in one go is a good feature to have UI wise (iow switch from top to bottom lighting or visa versa. 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 2.6.37] davinci videobuf fixes
On Tuesday, September 07, 2010 11:23:25 Hans Verkuil wrote: Hi Mauro, The following changes since commit 50b9d21ae2ac1b85be46f1ee5aa1b5e588622361: Jarod Wilson (1): V4L/DVB: mceusb: add two new ASUS device IDs are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git for-2.6.37 Hans Verkuil (1): videobuf-dma-sg: set correct size in last sg element Mats Randgaard (4): videobuf-core.c: Replaced BUG_ON with WARN_ON vpif_cap/disp: Removed section mismatch warning vpif_cap/disp: Replaced kmalloc with kzalloc vpif_cap/disp: Fixed strlcpy NULL pointer bug Added one more fix from Mats: vpif_cap: don't ignore return code of videobuf_poll_stream() Regards, Hans This patch series prepares for a future patch series that adds HDTV support to the davinci drivers. We (Tandberg) have those patches ready, but it needs more testing before we post them. Regarding the two videobuf patches: the dma-sg patch fixes a nasty memory corruption bug that took me several days to track down. It might be a candidate for 2.6.36 as well, but this bug has been there for ages and apparently nobody noticed, so I decided to do this for 2.6.37 only. The other videobuf patch changes a completely unnecessary BUG_ON to a WARN_ON. Regards, Hans drivers/media/video/davinci/vpif_capture.c |9 + drivers/media/video/davinci/vpif_display.c | 11 ++- drivers/media/video/videobuf-core.c|2 +- drivers/media/video/videobuf-dma-sg.c | 11 +++ include/media/videobuf-dma-sg.h|1 + 5 files changed, 20 insertions(+), 14 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 22/30] dvb: Convert mutex to semaphore
Get rid of init_MUTEX[_LOCKED]() and use sema_init() instead. Signed-off-by: Thomas Gleixner t...@linutronix.de Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: linux-media@vger.kernel.org --- drivers/media/dvb/dvb-core/dvb_frontend.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6/drivers/media/dvb/dvb-core/dvb_frontend.c === --- linux-2.6.orig/drivers/media/dvb/dvb-core/dvb_frontend.c +++ linux-2.6/drivers/media/dvb/dvb-core/dvb_frontend.c @@ -702,7 +702,7 @@ static void dvb_frontend_stop(struct dvb kthread_stop(fepriv-thread); - init_MUTEX (fepriv-sem); + sema_init(fepriv-sem, 1); fepriv-state = FESTATE_IDLE; /* paranoia check in case a signal arrived */ @@ -2061,7 +2061,7 @@ int dvb_register_frontend(struct dvb_ada } fepriv = fe-frontend_priv; - init_MUTEX (fepriv-sem); + sema_init(fepriv-sem, 1); init_waitqueue_head (fepriv-wait_queue); init_waitqueue_head (fepriv-events.wait_queue); mutex_init(fepriv-events.mtx); -- 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] Illuminators and status LED controls
On Tuesday, September 07, 2010 13:59:19 Hans de Goede wrote: Hi all, On 09/07/2010 11:47 AM, Hans Verkuil wrote: On Tuesday, September 07, 2010 11:44:18 Hans de Goede wrote: Replying to myself. On 09/07/2010 11:42 AM, Hans de Goede wrote: Hi, On 09/07/2010 09:30 AM, Hans Verkuil wrote: On Monday, September 06, 2010 20:11:05 Jean-Francois Moine wrote: Hi, This new proposal cancels the previous 'LED control' patch. Cheers. Hi Jean-Francois, You must also add support for these new controls in v4l2-ctrls.c in v4l2_ctrl_get_menu(), v4l2_ctrl_get_name() and v4l2_ctrl_fill(). How is CID_ILLUMINATORS supposed to work in the case of multiple lights? Wouldn't a bitmask type be more suitable to this than a menu type? There isn't a bitmask type at the moment, but this seems to be a pretty good candidate for a type like that. Actually, for the status led I would also use a bitmask since there may be multiple leds. I guess you would need two bitmasks: one to select auto vs manual, and one for the manual settings. So far I've not seen cameras with multiple status leds, I do have seen camera which have the following settings for their 1 led (logitech uvc cams): auto on off blinking So I think a menu type is better suited, and that is what the current (private) uvc control uses. The same argument more or less goes for the CID_ILLIMUNATORS controls. Also given that we currently don't have a bitmask type I think introducing one without a really really good reason is a bad idea as any exiting apps won't know how to deal with it. But I can guarantee that we will get video devices with multiple leds in the future. So we need to think *now* about how to do this. One simple option is of course to name the controls CID_ILLUMINATOR0 and CID_LED0. That way we can easily add LED1, LED2, etc. later without running into weird inconsistent control names. Naming them LED0 and ILLUMINATOR0 works for me. Note about the illuminator one, if you look at the patch it made the illuminator control a menu with the following options: Where in the patch? Am I missing something? Both off Top on, Bottom off Top off, Bottom on Both on Which raises the question do we leave this as is, or do we make this 2 boolean controls. I personally would like to vote for keeping it as is, as both lamps illuminate the same substrate in this case, and esp. switching between Top on, Bottom off to Top off, Bottom on in one go is a good feature to have UI wise (iow switch from top to bottom lighting or visa versa. The problem with having one control is that while this makes sense for this particular microscope, it doesn't make sense in general. Standard controls such as proposed by this patch should have a fixed type and consistent behavior. Note that I am also wondering whether it wouldn't be a good idea to use a menu for this, just as for the LEDs. In fact, perhaps they should use the same menu. While their purpose is different, they are quite similar in behavior. BTW, lovely word: 'illuminator'. Regards, Hans Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Illuminators and status LED controls
Hi, On 09/07/2010 04:50 PM, Hans Verkuil wrote: On Tuesday, September 07, 2010 13:59:19 Hans de Goede wrote: Hi all, On 09/07/2010 11:47 AM, Hans Verkuil wrote: On Tuesday, September 07, 2010 11:44:18 Hans de Goede wrote: Replying to myself. On 09/07/2010 11:42 AM, Hans de Goede wrote: Hi, On 09/07/2010 09:30 AM, Hans Verkuil wrote: On Monday, September 06, 2010 20:11:05 Jean-Francois Moine wrote: Hi, This new proposal cancels the previous 'LED control' patch. Cheers. Hi Jean-Francois, You must also add support for these new controls in v4l2-ctrls.c in v4l2_ctrl_get_menu(), v4l2_ctrl_get_name() and v4l2_ctrl_fill(). How is CID_ILLUMINATORS supposed to work in the case of multiple lights? Wouldn't a bitmask type be more suitable to this than a menu type? There isn't a bitmask type at the moment, but this seems to be a pretty good candidate for a type like that. Actually, for the status led I would also use a bitmask since there may be multiple leds. I guess you would need two bitmasks: one to select auto vs manual, and one for the manual settings. So far I've not seen cameras with multiple status leds, I do have seen camera which have the following settings for their 1 led (logitech uvc cams): auto on off blinking So I think a menu type is better suited, and that is what the current (private) uvc control uses. The same argument more or less goes for the CID_ILLIMUNATORS controls. Also given that we currently don't have a bitmask type I think introducing one without a really really good reason is a bad idea as any exiting apps won't know how to deal with it. But I can guarantee that we will get video devices with multiple leds in the future. So we need to think *now* about how to do this. One simple option is of course to name the controls CID_ILLUMINATOR0 and CID_LED0. That way we can easily add LED1, LED2, etc. later without running into weird inconsistent control names. Naming them LED0 and ILLUMINATOR0 works for me. Note about the illuminator one, if you look at the patch it made the illuminator control a menu with the following options: Where in the patch? Am I missing something? Both off Top on, Bottom off Top off, Bottom on Both on Which raises the question do we leave this as is, or do we make this 2 boolean controls. I personally would like to vote for keeping it as is, as both lamps illuminate the same substrate in this case, and esp. switching between Top on, Bottom off to Top off, Bottom on in one go is a good feature to have UI wise (iow switch from top to bottom lighting or visa versa. The problem with having one control is that while this makes sense for this particular microscope, it doesn't make sense in general. Actual it does atleast for microscopes in general a substrate under a microscope usually is either illuminated from above or below. Standard controls such as proposed by this patch should have a fixed type Although I agree with that sentiment in general I don't see this as an absolute need, apps should get the type by doing a query ctrl not by assuming they know it based on the cid. And esp. for menu controls this is not true, for example most devices have a light freq filter menu of: off 50 hz 60 hz Which matches what is documented in videodev2.h Where as some have: off 50 hz 60 hz auto hz Because they can (and default to) detect the light frequency automatically. consistent behavior. Note that I am also wondering whether it wouldn't be a good idea to use a menu for this, just as for the LEDs. I do agree that the illuminator ctrls should be a menu, that way the driver author can also choose wether to group 2 together in a single control or not we simply should not specify the menu values in the spec (the same can be said for the led case). Regards, Hams -- 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] Illuminators and status LED controls
On Tuesday, September 07, 2010 15:04:55 Hans de Goede wrote:
Hi,
On 09/07/2010 04:50 PM, Hans Verkuil wrote:
On Tuesday, September 07, 2010 13:59:19 Hans de Goede wrote:
Hi all,
On 09/07/2010 11:47 AM, Hans Verkuil wrote:
On Tuesday, September 07, 2010 11:44:18 Hans de Goede wrote:
Replying to myself.
On 09/07/2010 11:42 AM, Hans de Goede wrote:
Hi,
On 09/07/2010 09:30 AM, Hans Verkuil wrote:
On Monday, September 06, 2010 20:11:05 Jean-Francois Moine wrote:
Hi,
This new proposal cancels the previous 'LED control' patch.
Cheers.
Hi Jean-Francois,
You must also add support for these new controls in v4l2-ctrls.c in
v4l2_ctrl_get_menu(), v4l2_ctrl_get_name() and v4l2_ctrl_fill().
How is CID_ILLUMINATORS supposed to work in the case of multiple
lights?
Wouldn't a bitmask type be more suitable to this than a menu type?
There
isn't a bitmask type at the moment, but this seems to be a pretty good
candidate for a type like that.
Actually, for the status led I would also use a bitmask since there
may be
multiple leds. I guess you would need two bitmasks: one to select auto
vs
manual, and one for the manual settings.
So far I've not seen cameras with multiple status leds, I do have seen
camera
which have the following settings for their 1 led (logitech uvc cams):
auto
on
off
blinking
So I think a menu type is better suited, and that is what the current
(private)
uvc control uses.
The same argument more or less goes for the CID_ILLIMUNATORS controls.
Also given
that we currently don't have a bitmask type I think introducing one
without a really
really good reason is a bad idea as any exiting apps won't know how to
deal with it.
But I can guarantee that we will get video devices with multiple leds in
the
future. So we need to think *now* about how to do this. One simple option
is of course
to name the controls CID_ILLUMINATOR0 and CID_LED0. That way we can
easily add LED1,
LED2, etc. later without running into weird inconsistent control names.
Naming them LED0 and ILLUMINATOR0 works for me. Note about the illuminator
one,
if you look at the patch it made the illuminator control a menu with the
following
options:
Where in the patch? Am I missing something?
Both off
Top on, Bottom off
Top off, Bottom on
Both on
Which raises the question do we leave this as is, or do we make this 2
boolean
controls. I personally would like to vote for keeping it as is, as both
lamps
illuminate the same substrate in this case, and esp. switching between
Top on, Bottom off to Top off, Bottom on in one go is a good feature to
have
UI wise (iow switch from top to bottom lighting or visa versa.
The problem with having one control is that while this makes sense for this
particular microscope, it doesn't make sense in general.
Actual it does atleast for microscopes in general a substrate under a
microscope
usually is either illuminated from above or below.
Standard controls such as proposed by this patch should have a fixed type
Although I agree with that sentiment in general I don't see this as an
absolute
need, apps should get the type by doing a query ctrl not by assuming they
know it based on the cid.
And esp. for menu controls this is not true, for example
most devices have a light freq filter menu of:
off
50 hz
60 hz
Which matches what is documented in videodev2.h
Where as some have:
off
50 hz
60 hz
auto hz
Because they can (and default to) detect the light frequency automatically.
The v4l2 api allows drivers to selectively enable items from a menu. So this
control has a fixed menu type and a fixed menu contents. Some of the menu
choices are just not available for some drivers.
There are several advantages of sticking to one standard menu for standard
controls:
1) The contents of the menu can be defined centrally in v4l2-ctrls.c, which
ensures consistency. Not only of the menu texts, but also of how the
control behaves in various drivers.
2) It makes it possible to set the control directly from within a program.
This is currently true for *all* standard controls and breaking this for no
good reason is something that needs to be avoided. I don't think this
is a requirement in the spec at the moment, but I think it should be.
Just the fact that you can in theory put anything you want into a control,
doesn't mean that you should.
This looks pretty decent IMHO:
enum v4l2_illuminator {
V4L2_ILLUMINATOR_OFF = 0,
V4L2_ILLUMINATOR_ON = 1,
};
#define V4L2_CID_ILLUMINATOR_0 (V4L2_CID_BASE+37)
#define V4L2_CID_ILLUMINATOR_1 (V4L2_CID_BASE+38)
enum v4l2_led {
V4L2_LED_AUTO = 0,
V4L2_LED_OFF = 1,
V4L2_LED_ON = 2,
};
#define V4L2_CID_LED_0 (V4L2_CID_BASE+39)
Simple and straightforward.
consistent behavior.
[PATCH 1/2] V4L/DVB: dib7770: enable the current mirror
From: Olivier Grenie olivier.gre...@dibcom.fr
To improve performance on DiB7770-devices enabling the current mirror
is needed.
This patch adds an option to the dib7000p-driver to do that and it
creates a separate device-entry in dib0700-device to use those changes
on hardware which is using the DiB7770.
Cc: sta...@kernel.org
Signed-off-by: Olivier Grenie olivier.gre...@dibcom.fr
Signed-off-by: Patrick Boettcher patrick.boettc...@dibcom.fr
---
drivers/media/dvb/dvb-usb/dib0700_devices.c | 53 ++-
drivers/media/dvb/frontends/dib7000p.c |2 +
drivers/media/dvb/frontends/dib7000p.h |3 ++
3 files changed, 57 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c
b/drivers/media/dvb/dvb-usb/dib0700_devices.c
index f634d2e..f9766c7 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -940,6 +940,57 @@ static int stk7070p_frontend_attach(struct dvb_usb_adapter
*adap)
return adap-fe == NULL ? -ENODEV : 0;
}
+/* STK7770P */
+static struct dib7000p_config dib7770p_dib7000p_config = {
+ .output_mpeg2_in_188_bytes = 1,
+
+ .agc_config_count = 1,
+ .agc = dib7070_agc_config,
+ .bw = dib7070_bw_config_12_mhz,
+ .tuner_is_baseband = 1,
+ .spur_protect = 1,
+
+ .gpio_dir = DIB7000P_GPIO_DEFAULT_DIRECTIONS,
+ .gpio_val = DIB7000P_GPIO_DEFAULT_VALUES,
+ .gpio_pwm_pos = DIB7000P_GPIO_DEFAULT_PWM_POS,
+
+ .hostbus_diversity = 1,
+ .enable_current_mirror = 1,
+};
+
+static int stk7770p_frontend_attach(struct dvb_usb_adapter *adap)
+{
+ struct usb_device_descriptor *p = adap-dev-udev-descriptor;
+ if (p-idVendor == cpu_to_le16(USB_VID_PINNACLE)
+ p-idProduct == cpu_to_le16(USB_PID_PINNACLE_PCTV72E))
+ dib0700_set_gpio(adap-dev, GPIO6, GPIO_OUT, 0);
+ else
+ dib0700_set_gpio(adap-dev, GPIO6, GPIO_OUT, 1);
+ msleep(10);
+ dib0700_set_gpio(adap-dev, GPIO9, GPIO_OUT, 1);
+ dib0700_set_gpio(adap-dev, GPIO4, GPIO_OUT, 1);
+ dib0700_set_gpio(adap-dev, GPIO7, GPIO_OUT, 1);
+ dib0700_set_gpio(adap-dev, GPIO10, GPIO_OUT, 0);
+
+ dib0700_ctrl_clock(adap-dev, 72, 1);
+
+ msleep(10);
+ dib0700_set_gpio(adap-dev, GPIO10, GPIO_OUT, 1);
+ msleep(10);
+ dib0700_set_gpio(adap-dev, GPIO0, GPIO_OUT, 1);
+
+ if (dib7000p_i2c_enumeration(adap-dev-i2c_adap, 1, 18,
+dib7770p_dib7000p_config) != 0) {
+ err(%s: dib7000p_i2c_enumeration failed. Cannot continue\n,
+ __func__);
+ return -ENODEV;
+ }
+
+ adap-fe = dvb_attach(dib7000p_attach, adap-dev-i2c_adap, 0x80,
+ dib7770p_dib7000p_config);
+ return adap-fe == NULL ? -ENODEV : 0;
+}
+
/* DIB807x generic */
static struct dibx000_agc_config dib807x_agc_config[2] = {
{
@@ -2406,7 +2457,7 @@ struct dvb_usb_device_properties dib0700_devices[] = {
.pid_filter_count = 32,
.pid_filter = stk70x0p_pid_filter,
.pid_filter_ctrl = stk70x0p_pid_filter_ctrl,
- .frontend_attach = stk7070p_frontend_attach,
+ .frontend_attach = stk7770p_frontend_attach,
.tuner_attach = dib7770p_tuner_attach,
DIB0700_DEFAULT_STREAMING_CONFIG(0x02),
diff --git a/drivers/media/dvb/frontends/dib7000p.c
b/drivers/media/dvb/frontends/dib7000p.c
index 2e28b97..73f59ab 100644
--- a/drivers/media/dvb/frontends/dib7000p.c
+++ b/drivers/media/dvb/frontends/dib7000p.c
@@ -260,6 +260,8 @@ static void dib7000p_set_adc_state(struct dib7000p_state
*state, enum dibx000_ad
// dprintk( 908: %x, 909: %x\n, reg_908, reg_909);
+ reg_908 |= (state-cfg.enable_current_mirror 1) 7;
+
dib7000p_write_word(state, 908, reg_908);
dib7000p_write_word(state, 909, reg_909);
}
diff --git a/drivers/media/dvb/frontends/dib7000p.h
b/drivers/media/dvb/frontends/dib7000p.h
index 805dd13..04a7449 100644
--- a/drivers/media/dvb/frontends/dib7000p.h
+++ b/drivers/media/dvb/frontends/dib7000p.h
@@ -33,6 +33,9 @@ struct dib7000p_config {
int (*agc_control) (struct dvb_frontend *, u8 before);
u8 output_mode;
+
+ u8 enable_current_mirror : 1;
+
};
#define DEFAULT_DIB7000P_I2C_ADDRESS 18
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] V4L/DVB: dib7000p: add disable sample and hold, and diversity delay parameter
From: Olivier Grenie olivier.gre...@dibcom.fr
This patch improves the overall driver performance in
diversity-reception scenarios.
Signed-off-by: Olivier Grenie olivier.gre...@dibcom.fr
Signed-off-by: Patrick Boettcher patrick.boettc...@dibcom.fr
---
drivers/media/dvb/dvb-usb/dib0700_devices.c |1 +
drivers/media/dvb/frontends/dib7000p.c |6 +-
drivers/media/dvb/frontends/dib7000p.h |2 ++
3 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c
b/drivers/media/dvb/dvb-usb/dib0700_devices.c
index f9766c7..6015cfd 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -956,6 +956,7 @@ static struct dib7000p_config dib7770p_dib7000p_config = {
.hostbus_diversity = 1,
.enable_current_mirror = 1,
+ .disable_sample_and_hold = 0,
};
static int stk7770p_frontend_attach(struct dvb_usb_adapter *adap)
diff --git a/drivers/media/dvb/frontends/dib7000p.c
b/drivers/media/dvb/frontends/dib7000p.c
index 73f59ab..3aed0d4 100644
--- a/drivers/media/dvb/frontends/dib7000p.c
+++ b/drivers/media/dvb/frontends/dib7000p.c
@@ -260,6 +260,7 @@ static void dib7000p_set_adc_state(struct dib7000p_state
*state, enum dibx000_ad
// dprintk( 908: %x, 909: %x\n, reg_908, reg_909);
+ reg_909 |= (state-cfg.disable_sample_and_hold 1) 4;
reg_908 |= (state-cfg.enable_current_mirror 1) 7;
dib7000p_write_word(state, 908, reg_908);
@@ -780,7 +781,10 @@ static void dib7000p_set_channel(struct dib7000p_state
*state, struct dvb_fronte
default:
case GUARD_INTERVAL_1_32: value *= 1; break;
}
- state-div_sync_wait = (value * 3) / 2 + 32; // add 50% SFN margin +
compensate for one DVSY-fifo TODO
+ if (state-cfg.diversity_delay == 0)
+ state-div_sync_wait = (value * 3) / 2 + 48; // add 50% SFN
margin + compensate for one DVSY-fifo
+ else
+ state-div_sync_wait = (value * 3) / 2 +
state-cfg.diversity_delay; // add 50% SFN margin + compensate for one DVSY-fifo
/* deactive the possibility of diversity reception if extended
interleaver */
state-div_force_off = !1 ch-u.ofdm.transmission_mode !=
TRANSMISSION_MODE_8K;
diff --git a/drivers/media/dvb/frontends/dib7000p.h
b/drivers/media/dvb/frontends/dib7000p.h
index 04a7449..da17345 100644
--- a/drivers/media/dvb/frontends/dib7000p.h
+++ b/drivers/media/dvb/frontends/dib7000p.h
@@ -33,8 +33,10 @@ struct dib7000p_config {
int (*agc_control) (struct dvb_frontend *, u8 before);
u8 output_mode;
+ u8 disable_sample_and_hold : 1;
u8 enable_current_mirror : 1;
+ u8 diversity_delay;
};
--
1.7.0.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
Re: [PATCH 1/2] V4L/DVB: dib7770: enable the current mirror
Hi Mauro, On Tuesday 07 September 2010 17:50:45 pboettc...@kernellabs.com wrote: From: Olivier Grenie olivier.gre...@dibcom.fr To improve performance on DiB7770-devices enabling the current mirror is needed. This patch adds an option to the dib7000p-driver to do that and it creates a separate device-entry in dib0700-device to use those changes on hardware which is using the DiB7770. Cc: sta...@kernel.org Signed-off-by: Olivier Grenie olivier.gre...@dibcom.fr Signed-off-by: Patrick Boettcher patrick.boettc...@dibcom.fr --- drivers/media/dvb/dvb-usb/dib0700_devices.c | 53 ++- drivers/media/dvb/frontends/dib7000p.c | 2 + drivers/media/dvb/frontends/dib7000p.h |3 ++ 3 files changed, 57 insertions(+), 1 deletions(-) This is the patch I was talking to you about in my last Email. This one needs to be quickly applied to 2.6.35. Well ... quickly ... as soon as possible in sense of when you have a free time slot. This patch help to optimize the performance of the DiB7770-chip which can be found in several devices out there right now. It was tested and applied on 2.6.36-rc3, It should apply cleanly on 2.6.35. Thanks in advance for your help, Patrick. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Illuminators and status LED controls
Look for a recent patch I sent to the list for gspca_cpia for the Intel Play QX3 microscope. (The cpia2 driver handles the QX5) Illuminator seems to be the standard term in both microscopy and IR photgraphy. I also saw it in plain photography contexts. Just ask the Google... Regards, Andy Hans Verkuil hverk...@xs4all.nl wrote: On Tuesday, September 07, 2010 13:59:19 Hans de Goede wrote: Hi all, On 09/07/2010 11:47 AM, Hans Verkuil wrote: On Tuesday, September 07, 2010 11:44:18 Hans de Goede wrote: Replying to myself. On 09/07/2010 11:42 AM, Hans de Goede wrote: Hi, On 09/07/2010 09:30 AM, Hans Verkuil wrote: On Monday, September 06, 2010 20:11:05 Jean-Francois Moine wrote: Hi, This new proposal cancels the previous 'LED control' patch. Cheers. Hi Jean-Francois, You must also add support for these new controls in v4l2-ctrls.c in v4l2_ctrl_get_menu(), v4l2_ctrl_get_name() and v4l2_ctrl_fill(). How is CID_ILLUMINATORS supposed to work in the case of multiple lights? Wouldn't a bitmask type be more suitable to this than a menu type? There isn't a bitmask type at the moment, but this seems to be a pretty good candidate for a type like that. Actually, for the status led I would also use a bitmask since there may be multiple leds. I guess you would need two bitmasks: one to select auto vs manual, and one for the manual settings. So far I've not seen cameras with multiple status leds, I do have seen camera which have the following settings for their 1 led (logitech uvc cams): auto on off blinking So I think a menu type is better suited, and that is what the current (private) uvc control uses. The same argument more or less goes for the CID_ILLIMUNATORS controls. Also given that we currently don't have a bitmask type I think introducing one without a really really good reason is a bad idea as any exiting apps won't know how to deal with it. But I can guarantee that we will get video devices with multiple leds in the future. So we need to think *now* about how to do this. One simple option is of course to name the controls CID_ILLUMINATOR0 and CID_LED0. That way we can easily add LED1, LED2, etc. later without running into weird inconsistent control names. Naming them LED0 and ILLUMINATOR0 works for me. Note about the illuminator one, if you look at the patch it made the illuminator control a menu with the following options: Where in the patch? Am I missing something? Both off Top on, Bottom off Top off, Bottom on Both on Which raises the question do we leave this as is, or do we make this 2 boolean controls. I personally would like to vote for keeping it as is, as both lamps illuminate the same substrate in this case, and esp. switching between Top on, Bottom off to Top off, Bottom on in one go is a good feature to have UI wise (iow switch from top to bottom lighting or visa versa. The problem with having one control is that while this makes sense for this particular microscope, it doesn't make sense in general. Standard controls such as proposed by this patch should have a fixed type and consistent behavior. Note that I am also wondering whether it wouldn't be a good idea to use a menu for this, just as for the LEDs. In fact, perhaps they should use the same menu. While their purpose is different, they are quite similar in behavior. BTW, lovely word: 'illuminator'. Regards, Hans Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Illuminators and status LED controls
On Tue, 7 Sep 2010 17:30:33 +0200
Hans Verkuil hverk...@xs4all.nl wrote:
enum v4l2_illuminator {
V4L2_ILLUMINATOR_OFF = 0,
V4L2_ILLUMINATOR_ON = 1,
};
#define V4L2_CID_ILLUMINATOR_0 (V4L2_CID_BASE+37)
#define V4L2_CID_ILLUMINATOR_1 (V4L2_CID_BASE+38)
enum v4l2_led {
V4L2_LED_AUTO = 0,
V4L2_LED_OFF = 1,
V4L2_LED_ON = 2,
};
#define V4L2_CID_LED_0 (V4L2_CID_BASE+39)
Simple and straightforward.
Hi,
Hans (de Goede), is this OK for you? I think that if we find more
illuminators or LEDs on some devices, we may add more V4L2_CID_xxx_n
controls.
Hans (Verkuil), may we have the same enum's for both light types?
Something like:
enum v4l2_light {
V4L2_LIGHT_OFF = 0,
V4L2_LIGHT_ON = 1,
V4L2_LIGHT_AUTO = 2,
V4L2_LIGHT_BLINK = 3,
};
Regards.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Illuminators and status LED controls
On Tuesday, September 07, 2010 19:57:18 Jean-Francois Moine wrote:
On Tue, 7 Sep 2010 17:30:33 +0200
Hans Verkuil hverk...@xs4all.nl wrote:
enum v4l2_illuminator {
V4L2_ILLUMINATOR_OFF = 0,
V4L2_ILLUMINATOR_ON = 1,
};
#define V4L2_CID_ILLUMINATOR_0 (V4L2_CID_BASE+37)
#define V4L2_CID_ILLUMINATOR_1 (V4L2_CID_BASE+38)
enum v4l2_led {
V4L2_LED_AUTO = 0,
V4L2_LED_OFF = 1,
V4L2_LED_ON = 2,
};
#define V4L2_CID_LED_0 (V4L2_CID_BASE+39)
Simple and straightforward.
Hi,
Hans (de Goede), is this OK for you? I think that if we find more
illuminators or LEDs on some devices, we may add more V4L2_CID_xxx_n
controls.
Hans (Verkuil), may we have the same enum's for both light types?
Something like:
enum v4l2_light {
V4L2_LIGHT_OFF = 0,
V4L2_LIGHT_ON = 1,
V4L2_LIGHT_AUTO = 2,
V4L2_LIGHT_BLINK = 3,
};
I'm OK with that. Although 'blink' shouldn't be added yet unless we have a
driver that will actually make use of it.
Regards,
Hans
Regards.
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.26 and up: 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 Sep 7 19:00:05 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15139:6e0befab696a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 1c1371c2fe53ded8ede3a0404c9415fbf3321328 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: WARNINGS linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.36-rc2-armv5: ERRORS linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35.3-armv5-davinci: WARNINGS linux-2.6.36-rc2-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35.3-armv5-ixp: WARNINGS linux-2.6.36-rc2-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35.3-armv5-omap2: WARNINGS linux-2.6.36-rc2-armv5-omap2: ERRORS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS 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-rc2-i686: ERRORS linux-2.6.32.6-m32r: WARNINGS linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.36-rc2-m32r: ERRORS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.36-rc2-mips: ERRORS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: WARNINGS linux-2.6.36-rc2-powerpc64: ERRORS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS 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-rc2-x86_64: ERRORS linux-git-Module.symvers: ERRORS linux-git-armv5: ERRORS linux-git-armv5-davinci: ERRORS linux-git-armv5-ixp: ERRORS linux-git-armv5-omap2: ERRORS linux-git-i686: ERRORS linux-git-m32r: ERRORS linux-git-mips: ERRORS linux-git-powerpc64: ERRORS linux-git-x86_64: ERRORS spec: ERRORS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 0/4] FM Radio driver.
On Monday, August 30, 2010 13:38:18 Matti J. Aaltonen wrote:
Hi again,
and thanks for the comments.
I've left the audio codec out of this patch set.
Hans wrote:
In principle yes, but we haven't yet decided to implement those now, at
the moment the RDS interpretation is left completely to user space
applications.
Matti, is it even possible to use the current FM TX RDS API for this chip?
That API expects that the chip can generate the correct RDS packets based on
high-level data. If the chip can only handle 'raw' RDS packets (requiring a
userspace RDS encoder), then that API will never work.
But if this chip can indeed handle raw RDS only, then we need to add some
capability flags to signal that to userspace.
It is possible to use the current FM TX RDS API, the chip supports at least
most of it. I just haven't implemented the support into the driver yet,
for a multiple of reasons. I'm planning of adding that in the relatively
near future.
OK, good to know.
Anyhow, I've now added a way of telling that only raw RDS is supported.
Can we use one bit it the capability field for that?
I need to research this a bit. I intended to do that last weekend, but Real
Life (tm) interfered. I hope to get around it in the upcoming weekend.
I'm really sorry about the long delays on my side. Believe me, it's not
intentional.
+ struct wl1273_device *radio = ctrl-priv;
No need to use priv for this. You can use this instead:
static inline struct wl1273_device *to_radio(struct v4l2_ctrl *ctrl)
{
return container_of(ctrl-handler, struct wl1273_device,
ctrl_handler);
}
Fixed. I just didn't come to think that it can be done like this.
+ dev_dbg(radio-dev, %s\n, __func__);
+ return r;
+}
Was the documentation on the control handler understandable enough? Any
comments on how to improve the API or documentation? It's very new, so
I'm interested in hearing about your experiences implementing this API.
I think the documentation is OK. But I didn't have time to dwell on it,
but on the other hand I remember thinking that the new API is better
than the previous one...
That's good news :-)
But what's the motivation behind having subdevices? You'll hardly
have several FM radios and want to do the same things on each
one at the same time?
Right now this driver is a platform device if I'm not mistaken. But what if
someone would stick this wl1273 on a USB stick? Or on some PCI board?
Implementing the core wl1273 driver as a subdevice makes it independent from
how it is assembled in the final product.
There are other reasons as well, but it all boils down to creating an abstract
interface towards hardware devices so that you no longer have to care about
how they are hooked up physically to your platform/board/SoC/whatever.
No need to use priv.
...
First V4L2_CID_FM_BAND using new_std instead of new_std_menu (which it
should
be).
...
And a second?!
+ if (ctrl) {
+ ctrl-is_volatile = 1;
+ ctrl-priv = radio;
+ }
And it is volatile? I thought that the ANTENNA_CAPACITOR was volatile.
Something is messed up here.
Fixed. Yes, that was completely messed up...
I hope to have the final comments ready this weekend. It's high time to get
this out of the door.
Regards,
Hans
Thanks...
Matti
Matti J. Aaltonen (4):
V4L2: Add seek spacing and FM RX class.
MFD: WL1273 FM Radio: MFD driver for the FM radio.
V4L2: WL1273 FM Radio: Controls for the FM radio.
Documentation: v4l: Add hw_seek spacing and FM_RX class
Documentation/DocBook/v4l/controls.xml | 71 +
Documentation/DocBook/v4l/dev-rds.xml |5 +
.../DocBook/v4l/vidioc-s-hw-freq-seek.xml | 10 +-
drivers/media/radio/Kconfig| 15 +
drivers/media/radio/Makefile |1 +
drivers/media/radio/radio-wl1273.c | 1935
drivers/media/video/v4l2-ctrls.c | 12 +
drivers/mfd/Kconfig|5 +
drivers/mfd/Makefile |2 +
drivers/mfd/wl1273-core.c | 612 +++
include/linux/mfd/wl1273-core.h| 314
include/linux/videodev2.h | 16 +-
12 files changed, 2995 insertions(+), 3 deletions(-)
create mode 100644 drivers/media/radio/radio-wl1273.c
create mode 100644 drivers/mfd/wl1273-core.c
create mode 100644 include/linux/mfd/wl1273-core.h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the
Re: [PATCH] Illuminators and status LED controls
Hello, On Mon, Sep 06, 2010 at 08:11:05PM +0200, ext Jean-Francois Moine wrote: Hi, This new proposal cancels the previous 'LED control' patch. Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ Apologies if this has been already discussed but, doesn't this patch duplicates the same feature present nowadays under include/linux/leds.h ?? I mean, if you want to control leds, I think we already have that API, no? BR, --- Eduardo Valentin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] V4L/DVB: radio-si4713: Add regulator framework support
Hello Jarkko,
On Sun, Jun 13, 2010 at 08:09:28PM +0200, Jarkko Nikula wrote:
Convert the driver to use regulator framework instead of set_power callback.
This with gpio_reset platform data provide cleaner way to manage chip VIO,
VDD and reset signal inside the driver.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
---
I don't have specifications for this chip so I don't know how long the
reset signal must be active after power-up. I used 50 us from Maemo
kernel sources for Nokia N900 and I can successfully enable-disable
transmitter on N900 with vdd power cycling.
---
drivers/media/radio/radio-si4713.c | 20 ++-
drivers/media/radio/si4713-i2c.c | 48 ---
drivers/media/radio/si4713-i2c.h |3 +-
include/media/si4713.h |3 +-
Could you please elaborate a bit more on the fact that you have put vio on
the platform driver and vdd on the i2c driver?
4 files changed, 60 insertions(+), 14 deletions(-)
diff --git a/drivers/media/radio/radio-si4713.c
b/drivers/media/radio/radio-si4713.c
index 0a9fc4d..c666012 100644
--- a/drivers/media/radio/radio-si4713.c
+++ b/drivers/media/radio/radio-si4713.c
@@ -28,6 +28,7 @@
#include linux/i2c.h
#include linux/videodev2.h
#include linux/slab.h
+#include linux/regulator/consumer.h
#include media/v4l2-device.h
#include media/v4l2-common.h
#include media/v4l2-ioctl.h
@@ -48,6 +49,7 @@ MODULE_VERSION(0.0.1);
struct radio_si4713_device {
struct v4l2_device v4l2_dev;
struct video_device *radio_dev;
+ struct regulator*reg_vio;
};
/* radio_si4713_fops - file operations interface */
@@ -283,12 +285,22 @@ static int radio_si4713_pdriver_probe(struct
platform_device *pdev)
goto free_rsdev;
}
+ rsdev-reg_vio = regulator_get(pdev-dev, vio);
+ if (IS_ERR(rsdev-reg_vio)) {
+ dev_err(pdev-dev, Cannot get vio regulator\n);
+ rval = PTR_ERR(rsdev-reg_vio);
+ goto unregister_v4l2_dev;
+ }
+ rval = regulator_enable(rsdev-reg_vio);
+ if (rval)
+ goto reg_put;
+
adapter = i2c_get_adapter(pdata-i2c_bus);
if (!adapter) {
dev_err(pdev-dev, Cannot get i2c adapter %d\n,
pdata-i2c_bus);
rval = -ENODEV;
- goto unregister_v4l2_dev;
+ goto reg_disable;
}
sd = v4l2_i2c_new_subdev_board(rsdev-v4l2_dev, adapter, si4713_i2c,
@@ -322,6 +334,10 @@ free_vdev:
video_device_release(rsdev-radio_dev);
put_adapter:
i2c_put_adapter(adapter);
+reg_disable:
+ regulator_disable(rsdev-reg_vio);
+reg_put:
+ regulator_put(rsdev-reg_vio);
unregister_v4l2_dev:
v4l2_device_unregister(rsdev-v4l2_dev);
free_rsdev:
@@ -343,6 +359,8 @@ static int __exit radio_si4713_pdriver_remove(struct
platform_device *pdev)
video_unregister_device(rsdev-radio_dev);
i2c_put_adapter(client-adapter);
+ regulator_disable(rsdev-reg_vio);
+ regulator_put(rsdev-reg_vio);
v4l2_device_unregister(rsdev-v4l2_dev);
kfree(rsdev);
diff --git a/drivers/media/radio/si4713-i2c.c
b/drivers/media/radio/si4713-i2c.c
index ab63dd5..4b5470c 100644
--- a/drivers/media/radio/si4713-i2c.c
+++ b/drivers/media/radio/si4713-i2c.c
@@ -27,6 +27,8 @@
#include linux/interrupt.h
#include linux/i2c.h
#include linux/slab.h
+#include linux/gpio.h
+#include linux/regulator/consumer.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include media/v4l2-common.h
@@ -369,7 +371,12 @@ static int si4713_powerup(struct si4713_device *sdev)
if (sdev-power_state)
return 0;
- sdev-platform_data-set_power(1);
+ regulator_enable(sdev-reg_vdd);
+ if (gpio_is_valid(sdev-gpio_reset)) {
+ udelay(50);
+ gpio_set_value(sdev-gpio_reset, 1);
+ }
+
err = si4713_send_command(sdev, SI4713_CMD_POWER_UP,
args, ARRAY_SIZE(args),
resp, ARRAY_SIZE(resp),
@@ -384,7 +391,9 @@ static int si4713_powerup(struct si4713_device *sdev)
err = si4713_write_property(sdev, SI4713_GPO_IEN,
SI4713_STC_INT | SI4713_CTS);
} else {
- sdev-platform_data-set_power(0);
+ if (gpio_is_valid(sdev-gpio_reset))
+ gpio_set_value(sdev-gpio_reset, 0);
+ regulator_disable(sdev-reg_vdd);
}
return err;
@@ -411,7 +420,9 @@ static int si4713_powerdown(struct si4713_device *sdev)
v4l2_dbg(1, debug, sdev-sd, Power down response: 0x%02x\n,
resp[0]);
v4l2_dbg(1, debug, sdev-sd, Device in reset
Re: [PATCH 1/2] V4L/DVB: radio-si4713: Release i2c adapter in driver cleanup paths
Jarkko and Mauro,
Apologies for the long delay.
On Sun, Jun 13, 2010 at 08:09:27PM +0200, Jarkko Nikula wrote:
Call to i2c_put_adapter was missing in radio_si4713_pdriver_probe and
radio_si4713_pdriver_remove.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Acked-by: Eduardo Valentin eduardo.valen...@nokia.com
---
drivers/media/radio/radio-si4713.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/radio/radio-si4713.c
b/drivers/media/radio/radio-si4713.c
index 13554ab..0a9fc4d 100644
--- a/drivers/media/radio/radio-si4713.c
+++ b/drivers/media/radio/radio-si4713.c
@@ -296,14 +296,14 @@ static int radio_si4713_pdriver_probe(struct
platform_device *pdev)
if (!sd) {
dev_err(pdev-dev, Cannot get v4l2 subdevice\n);
rval = -ENODEV;
- goto unregister_v4l2_dev;
+ goto put_adapter;
}
rsdev-radio_dev = video_device_alloc();
if (!rsdev-radio_dev) {
dev_err(pdev-dev, Failed to alloc video device.\n);
rval = -ENOMEM;
- goto unregister_v4l2_dev;
+ goto put_adapter;
}
memcpy(rsdev-radio_dev, radio_si4713_vdev_template,
@@ -320,6 +320,8 @@ static int radio_si4713_pdriver_probe(struct
platform_device *pdev)
free_vdev:
video_device_release(rsdev-radio_dev);
+put_adapter:
+ i2c_put_adapter(adapter);
unregister_v4l2_dev:
v4l2_device_unregister(rsdev-v4l2_dev);
free_rsdev:
@@ -335,8 +337,12 @@ static int __exit radio_si4713_pdriver_remove(struct
platform_device *pdev)
struct radio_si4713_device *rsdev = container_of(v4l2_dev,
struct radio_si4713_device,
v4l2_dev);
+ struct v4l2_subdev *sd = list_entry(v4l2_dev-subdevs.next,
+ struct v4l2_subdev, list);
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
video_unregister_device(rsdev-radio_dev);
+ i2c_put_adapter(client-adapter);
v4l2_device_unregister(rsdev-v4l2_dev);
kfree(rsdev);
--
1.7.1
--
---
Eduardo Valentin
--
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] Illuminators and status LED controls
It has already been discussed. Please check the list archives for the past few days. Do you know of any V4L2 application developer or development team that prefers to use a separate API just to turn lights on and off, when all other aspects of the incoming video are controlled with the V4L2 control API? (That question is mostly rhetorical, but I'd still actually be interested from video app developers.) Regards, Andy Eduardo Valentin eduardo.valen...@nokia.com wrote: Hello, On Mon, Sep 06, 2010 at 08:11:05PM +0200, ext Jean-Francois Moine wrote: Hi, This new proposal cancels the previous 'LED control' patch. Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ Apologies if this has been already discussed but, doesn't this patch duplicates the same feature present nowadays under include/linux/leds.h ?? I mean, if you want to control leds, I think we already have that API, no? BR, --- Eduardo Valentin -- 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
DIKOM DK300: Kernel hangs after suspend to ram
Hi to all! I'm trying to use my Dikom DK-300 usb dvb-t device connected to an old laptop used as media player. The device works well but if I suspend the pc to ram (S3) when the Dikom usb stick is plugged in, the system hangs during the resume phase. So I've tried to create two scripts. The first one removes the driver before sleeping (the script is in the /etc/acpi/suspend.d directory) and the second one reloads it during the resume phase (this script is in /etc/acpi/resume.d directory). I've also inserted in the scripts some logs and it seems that the driver is correctly removed before the suspension, but then the pc hangs when resuming. Do you have some suggestion on how to resolve? I suspect that something in the GPIO setting is not corrected, but I don't know very well how to check that (now I've access to a windows xp virtualbox machine and a real windows vista system which maybe I can use to test/debug the correctness of the patch I postes some time ago). Thank you, Andrea Amorosi -- 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] Illuminators and status LED controls
On Tuesday, September 07, 2010 20:42:07 Hans Verkuil wrote:
On Tuesday, September 07, 2010 19:57:18 Jean-Francois Moine wrote:
On Tue, 7 Sep 2010 17:30:33 +0200
Hans Verkuil hverk...@xs4all.nl wrote:
enum v4l2_illuminator {
V4L2_ILLUMINATOR_OFF = 0,
V4L2_ILLUMINATOR_ON = 1,
};
#define V4L2_CID_ILLUMINATOR_0 (V4L2_CID_BASE+37)
#define V4L2_CID_ILLUMINATOR_1 (V4L2_CID_BASE+38)
enum v4l2_led {
V4L2_LED_AUTO = 0,
V4L2_LED_OFF = 1,
V4L2_LED_ON = 2,
};
#define V4L2_CID_LED_0 (V4L2_CID_BASE+39)
Simple and straightforward.
Hi,
Hans (de Goede), is this OK for you? I think that if we find more
illuminators or LEDs on some devices, we may add more V4L2_CID_xxx_n
controls.
Hans (Verkuil), may we have the same enum's for both light types?
Something like:
enum v4l2_light {
V4L2_LIGHT_OFF = 0,
V4L2_LIGHT_ON = 1,
V4L2_LIGHT_AUTO = 2,
V4L2_LIGHT_BLINK = 3,
};
I'm OK with that. Although 'blink' shouldn't be added yet unless we have a
driver that will actually make use of it.
I realized something else: while for us programmers it is perfectly natural
to start counting at 0, for the rest of the world it is probably more
understandable to start counting at 1. I know it goes against our religion,
but sometimes you just have to conform. :-)
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] rc-core: ir-core to rc-core conversion (v2)
This is my current patch queue, the main change is to make struct rc_dev the primary interface for rc drivers and to abstract away the fact that there's an input device lurking in there somewhere. The first three patches in the set are preparations for the change. I've also converted winbond-cir over to rc-core. Given the changes, these patches touch every single driver. Obviously I haven't tested them all due to a lack of hardware (I have made sure that all drivers compile without any warnings and I have tested the end result on mceusb and winbond-cir hardware). v2: rebased to take recent streamzap driver changes into account --- David Härdeman (5): rc-code: merge and rename ir-core rc-core: remove remaining users of the ir-functions keyhandlers imon: split mouse events to a separate input dev rc-core: make struct rc_dev the primary interface for rc drivers rc-core: convert winbond-cir drivers/input/misc/Kconfig | 18 drivers/input/misc/Makefile |1 drivers/input/misc/winbond-cir.c| 1608 --- drivers/media/IR/Kconfig| 17 drivers/media/IR/Makefile |4 drivers/media/IR/ene_ir.c | 121 +- drivers/media/IR/ene_ir.h |3 drivers/media/IR/imon.c | 267 +++- drivers/media/IR/ir-core-priv.h | 26 drivers/media/IR/ir-functions.c | 98 -- drivers/media/IR/ir-jvc-decoder.c | 13 drivers/media/IR/ir-keytable.c | 565 - drivers/media/IR/ir-lirc-codec.c| 111 +- drivers/media/IR/ir-nec-decoder.c | 15 drivers/media/IR/ir-raw-event.c | 379 -- drivers/media/IR/ir-rc5-decoder.c | 13 drivers/media/IR/ir-rc5-sz-decoder.c| 13 drivers/media/IR/ir-rc6-decoder.c | 17 drivers/media/IR/ir-sony-decoder.c | 11 drivers/media/IR/ir-sysfs.c | 341 -- drivers/media/IR/mceusb.c | 93 +- drivers/media/IR/rc-core.c | 1317 ++ drivers/media/IR/rc-map.c | 107 -- drivers/media/IR/streamzap.c| 68 - drivers/media/IR/winbond-cir.c | 934 drivers/media/dvb/dm1105/dm1105.c | 40 - drivers/media/dvb/dvb-usb/dib0700.h |2 drivers/media/dvb/dvb-usb/dib0700_core.c| 11 drivers/media/dvb/dvb-usb/dib0700_devices.c | 116 +- drivers/media/dvb/dvb-usb/dvb-usb-remote.c | 78 + drivers/media/dvb/dvb-usb/dvb-usb.h | 12 drivers/media/dvb/mantis/mantis_common.h|4 drivers/media/dvb/mantis/mantis_input.c | 74 + drivers/media/dvb/siano/smscoreapi.c|2 drivers/media/dvb/siano/smsir.c | 52 - drivers/media/dvb/siano/smsir.h |3 drivers/media/dvb/ttpci/budget-ci.c | 49 - drivers/media/video/bt8xx/bttv-input.c | 68 - drivers/media/video/bt8xx/bttvp.h |1 drivers/media/video/cx18/cx18-i2c.c |1 drivers/media/video/cx23885/cx23885-input.c | 64 + drivers/media/video/cx23885/cx23885.h |3 drivers/media/video/cx88/cx88-input.c | 86 + drivers/media/video/em28xx/em28xx-input.c | 72 + drivers/media/video/ir-kbd-i2c.c| 39 - drivers/media/video/ivtv/ivtv-i2c.c |3 drivers/media/video/saa7134/saa7134-input.c | 122 +- drivers/staging/tm6000/tm6000-input.c | 97 +- include/media/ir-common.h | 33 - include/media/ir-core.h | 193 +-- include/media/ir-kbd-i2c.h |6 51 files changed, 3175 insertions(+), 4216 deletions(-) delete mode 100644 drivers/input/misc/winbond-cir.c delete mode 100644 drivers/media/IR/ir-keytable.c delete mode 100644 drivers/media/IR/ir-raw-event.c delete mode 100644 drivers/media/IR/ir-sysfs.c create mode 100644 drivers/media/IR/rc-core.c delete mode 100644 drivers/media/IR/rc-map.c create mode 100644 drivers/media/IR/winbond-cir.c -- David Härdeman -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] rc-core: remove remaining users of the ir-functions keyhandlers
This patch removes the remaining usages of the ir_input_nokey() and
ir_input_keydown() functions provided by drivers/media/IR/ir-functions.c
by using the corresponding functionality in rc-core directly instead.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/IR/ir-functions.c | 98 ++-
drivers/media/IR/rc-core.c | 115 ---
drivers/media/video/bt8xx/bttv-input.c | 27 ++
drivers/media/video/bt8xx/bttvp.h |1
drivers/media/video/cx18/cx18-i2c.c |1
drivers/media/video/cx88/cx88-input.c | 24 ++
drivers/media/video/ir-kbd-i2c.c| 14 ---
drivers/media/video/ivtv/ivtv-i2c.c |3 -
drivers/media/video/saa7134/saa7134-input.c | 50 ++--
drivers/staging/tm6000/tm6000-input.c | 12 +--
include/media/ir-common.h | 30 +--
include/media/ir-core.h |2
include/media/ir-kbd-i2c.h |4 -
13 files changed, 131 insertions(+), 250 deletions(-)
diff --git a/drivers/media/IR/ir-functions.c b/drivers/media/IR/ir-functions.c
index db591e4..5fb7d0c 100644
--- a/drivers/media/IR/ir-functions.c
+++ b/drivers/media/IR/ir-functions.c
@@ -1,7 +1,7 @@
/*
- *
- * some common structs and functions to handle infrared remotes via
- * input layer ...
+ * some common functions to handle infrared remote protocol decoding for
+ * drivers which have not yet been (or can't be) converted to use the
+ * regular protocol decoders...
*
* (c) 2003 Gerd Knorr kra...@bytesex.org [SuSE Labs]
*
@@ -31,67 +31,6 @@
MODULE_AUTHOR(Gerd Knorr kra...@bytesex.org [SuSE Labs]);
MODULE_LICENSE(GPL);
-static int repeat = 1;
-module_param(repeat, int, 0444);
-MODULE_PARM_DESC(repeat,auto-repeat for IR keys (default: on));
-
-/* --
*/
-
-static void ir_input_key_event(struct input_dev *dev, struct ir_input_state
*ir)
-{
- if (KEY_RESERVED == ir-keycode) {
- printk(KERN_INFO %s: unknown key: key=0x%02x down=%d\n,
- dev-name, ir-ir_key, ir-keypressed);
- return;
- }
- IR_dprintk(1,%s: key event code=%d down=%d\n,
- dev-name,ir-keycode,ir-keypressed);
- input_report_key(dev,ir-keycode,ir-keypressed);
- input_sync(dev);
-}
-
-/* --
*/
-
-int ir_input_init(struct input_dev *dev, struct ir_input_state *ir,
- const u64 ir_type)
-{
- ir-ir_type = ir_type;
-
- if (repeat)
- set_bit(EV_REP, dev-evbit);
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(ir_input_init);
-
-
-void ir_input_nokey(struct input_dev *dev, struct ir_input_state *ir)
-{
- if (ir-keypressed) {
- ir-keypressed = 0;
- ir_input_key_event(dev,ir);
- }
-}
-EXPORT_SYMBOL_GPL(ir_input_nokey);
-
-void ir_input_keydown(struct input_dev *dev, struct ir_input_state *ir,
- u32 ir_key)
-{
- u32 keycode = ir_g_keycode_from_table(dev, ir_key);
-
- if (ir-keypressed ir-keycode != keycode) {
- ir-keypressed = 0;
- ir_input_key_event(dev,ir);
- }
- if (!ir-keypressed) {
- ir-ir_key = ir_key;
- ir-keycode = keycode;
- ir-keypressed = 1;
- ir_input_key_event(dev,ir);
- }
-}
-EXPORT_SYMBOL_GPL(ir_input_keydown);
-
/* --
*/
/* extract mask bits out of data and pack them into the result */
u32 ir_extract_bits(u32 data, u32 mask)
@@ -284,7 +223,7 @@ void ir_rc5_timer_end(unsigned long data)
{
struct card_ir *ir = (struct card_ir *)data;
struct timeval tv;
- unsigned long current_jiffies, timeout;
+ unsigned long current_jiffies;
u32 gap;
u32 rc5 = 0;
@@ -325,32 +264,11 @@ void ir_rc5_timer_end(unsigned long data)
u32 toggle = RC5_TOGGLE(rc5);
u32 instr = RC5_INSTR(rc5);
- /* Good code, decide if repeat/repress */
- if (toggle != RC5_TOGGLE(ir-last_rc5) ||
- instr != RC5_INSTR(ir-last_rc5)) {
- IR_dprintk(1, ir-common: instruction %x,
toggle %x\n, instr,
- toggle);
- ir_input_nokey(ir-dev, ir-ir);
- ir_input_keydown(ir-dev, ir-ir, instr);
- }
-
- /* Set/reset key-up timer */
- timeout = current_jiffies +
- msecs_to_jiffies(ir-rc5_key_timeout);
- mod_timer(ir-timer_keyup, timeout);
-
- /* Save code for repeat test
[PATCH 3/5] imon: split mouse events to a separate input dev
This is a stab at separating the mouse (and front panel/knob) events
out to a separate input device. This is necessary in preparation for
the next patch which makes the rc-core input dev opaque to rc
drivers.
I can't verify the correctness of the patch beyond the fact that it
compiles without warnings. The driver has resisted most of my
attempts at understanding it properly...for example, the double calls
to le64_to_cpu() and be64_to_cpu() which are applied in
imon_incoming_packet() and imon_panel_key_lookup() would amount
to a bswab64() call, irregardless of the cpu endianness, and I think
the code wouldn't have worked on a big-endian machine...
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/IR/imon.c | 261 +++
1 files changed, 150 insertions(+), 111 deletions(-)
diff --git a/drivers/media/IR/imon.c b/drivers/media/IR/imon.c
index c185422..e1e0ca1 100644
--- a/drivers/media/IR/imon.c
+++ b/drivers/media/IR/imon.c
@@ -121,21 +121,27 @@ struct imon_context {
u16 vendor; /* usb vendor ID */
u16 product;/* usb product ID */
- struct input_dev *idev; /* input device for remote */
+ struct input_dev *rdev; /* input device for remote */
+ struct input_dev *idev; /* input device for front panel/knob and
+* remote (fake) mouse
+*/
struct input_dev *touch;/* input device for touchscreen */
u32 kc; /* current input keycode */
u32 last_keycode; /* last reported input keycode */
+ u32 rc_scancode;/* the computed remote scancode */
+ u8 rc_toggle; /* the computed remote toggle */
u64 ir_type;/* iMON or MCE (RC6) IR protocol? */
- u8 mce_toggle_bit; /* last mce toggle bit */
bool release_code; /* some keys send a release code */
u8 display_type;/* store the display type */
bool pad_mouse; /* toggle kbd(0)/mouse(1) mode */
+ char name_rdev[128];/* rc device name */
+ char phys_rdev[64]; /* rc device phys path */
+
char name_idev[128];/* input device name */
char phys_idev[64]; /* input device phys path */
- struct timer_list itimer; /* input device timer, need for rc6 */
char name_touch[128]; /* touch screen name */
char phys_touch[64];/* touch screen phys path */
@@ -956,17 +962,6 @@ static void usb_tx_callback(struct urb *urb)
}
/**
- * mce/rc6 keypresses have no distinct release code, use timer
- */
-static void imon_mce_timeout(unsigned long data)
-{
- struct imon_context *ictx = (struct imon_context *)data;
-
- input_report_key(ictx-idev, ictx-last_keycode, 0);
- input_sync(ictx-idev);
-}
-
-/**
* report touchscreen input
*/
static void imon_touch_display_timeout(unsigned long data)
@@ -1006,9 +1001,6 @@ int imon_ir_change_protocol(void *priv, u64 ir_type)
dev_dbg(dev, Configuring IR receiver for MCE protocol\n);
ir_proto_packet[0] = 0x01;
pad_mouse = false;
- init_timer(ictx-itimer);
- ictx-itimer.data = (unsigned long)ictx;
- ictx-itimer.function = imon_mce_timeout;
break;
case IR_TYPE_UNKNOWN:
case IR_TYPE_OTHER:
@@ -1147,20 +1139,21 @@ static int stabilize(int a, int b, u16 timeout, u16
threshold)
return result;
}
-static u32 imon_remote_key_lookup(struct imon_context *ictx, u32 hw_code)
+static u32 imon_remote_key_lookup(struct imon_context *ictx, u32 scancode)
{
- u32 scancode = be32_to_cpu(hw_code);
u32 keycode;
u32 release;
bool is_release_code = false;
/* Look for the initial press of a button */
- keycode = ir_g_keycode_from_table(ictx-idev, scancode);
+ keycode = ir_g_keycode_from_table(ictx-rdev, scancode);
+ ictx-rc_toggle = 0x0;
+ ictx-rc_scancode = scancode;
/* Look for the release of a button */
if (keycode == KEY_RESERVED) {
release = scancode ~0x4000;
- keycode = ir_g_keycode_from_table(ictx-idev, release);
+ keycode = ir_g_keycode_from_table(ictx-rdev, release);
if (keycode != KEY_RESERVED)
is_release_code = true;
}
@@ -1170,9 +1163,8 @@ static u32 imon_remote_key_lookup(struct imon_context
*ictx, u32 hw_code)
return keycode;
}
-static u32 imon_mce_key_lookup(struct imon_context *ictx, u32 hw_code)
+static u32 imon_mce_key_lookup(struct imon_context *ictx, u32 scancode)
{
- u32 scancode = be32_to_cpu(hw_code);
u32 keycode;
#define
Re: [PATCH] Illuminators and status LED controls
On Tue, 7 Sep 2010, Hans Verkuil wrote:
On Tuesday, September 07, 2010 20:42:07 Hans Verkuil wrote:
On Tuesday, September 07, 2010 19:57:18 Jean-Francois Moine wrote:
On Tue, 7 Sep 2010 17:30:33 +0200
Hans Verkuil hverk...@xs4all.nl wrote:
enum v4l2_illuminator {
V4L2_ILLUMINATOR_OFF = 0,
V4L2_ILLUMINATOR_ON = 1,
};
#define V4L2_CID_ILLUMINATOR_0 (V4L2_CID_BASE+37)
#define V4L2_CID_ILLUMINATOR_1 (V4L2_CID_BASE+38)
enum v4l2_led {
V4L2_LED_AUTO = 0,
V4L2_LED_OFF = 1,
V4L2_LED_ON = 2,
};
#define V4L2_CID_LED_0 (V4L2_CID_BASE+39)
Simple and straightforward.
Hi,
Hans (de Goede), is this OK for you? I think that if we find more
illuminators or LEDs on some devices, we may add more V4L2_CID_xxx_n
controls.
Hans (Verkuil), may we have the same enum's for both light types?
Something like:
enum v4l2_light {
V4L2_LIGHT_OFF = 0,
V4L2_LIGHT_ON = 1,
V4L2_LIGHT_AUTO = 2,
V4L2_LIGHT_BLINK = 3,
};
I'm OK with that. Although 'blink' shouldn't be added yet unless we have a
driver that will actually make use of it.
I realized something else: while for us programmers it is perfectly natural
to start counting at 0, for the rest of the world it is probably more
understandable to start counting at 1. I know it goes against our religion,
but sometimes you just have to conform. :-)
Regards,
Hans
Sorry about the long silence from here, but there has been illness in the
family. I do keep trying to watch whatever is going on.
Hans, I agree with your general characterization of the public's
perception of 0 versus 1. But on this particular occasion I suspect that
the general public would see that 0 corresponds more naturally to off
than 1 does.
Hoping that all is well with you and others.
Cheers, and this is just my two cents on a trivial issue.
Theodore Kilgore
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Illuminators and status LED controls
Hi,
On 09/07/2010 05:30 PM, Hans Verkuil wrote:
On Tuesday, September 07, 2010 15:04:55 Hans de Goede wrote:
Hi,
On 09/07/2010 04:50 PM, Hans Verkuil wrote:
snip
Both off
Top on, Bottom off
Top off, Bottom on
Both on
Which raises the question do we leave this as is, or do we make this 2 boolean
controls. I personally would like to vote for keeping it as is, as both lamps
illuminate the same substrate in this case, and esp. switching between
Top on, Bottom off to Top off, Bottom on in one go is a good feature to have
UI wise (iow switch from top to bottom lighting or visa versa.
The problem with having one control is that while this makes sense for this
particular microscope, it doesn't make sense in general.
Actual it does atleast for microscopes in general a substrate under a microscope
usually is either illuminated from above or below.
Standard controls such as proposed by this patch should have a fixed type
Although I agree with that sentiment in general I don't see this as an absolute
need, apps should get the type by doing a query ctrl not by assuming they
know it based on the cid.
And esp. for menu controls this is not true, for example
most devices have a light freq filter menu of:
off
50 hz
60 hz
Which matches what is documented in videodev2.h
Where as some have:
off
50 hz
60 hz
auto hz
Because they can (and default to) detect the light frequency automatically.
The v4l2 api allows drivers to selectively enable items from a menu. So this
control has a fixed menu type and a fixed menu contents. Some of the menu
choices are just not available for some drivers.
This is not possible:
Quoting from:
http://www.linuxtv.org/downloads/v4l-dvb-apis/re61.html
Menu items are enumerated by calling VIDIOC_QUERYMENU with successive index values
from struct v4l2_queryctrl minimum (0) to maximum, inclusive.
And many apps are coded this way, so we cannot simply skip values in a
menu enum just because a driver does not support them, this would
break apps as they (rightfully) don't expect an error when
calling VIDIOC_QUERYMENU with an index between minimum and
maximum, so given for example:
enum v4l2_led {
V4L2_LED_AUTO = 0,
V4L2_LED_BLINK = 1,
V4L2_LED_OFF = 2,
V4L2_LED_ON = 3,
};
Drivers which do not support blink would still need to report a minimum
and maximum of 0 and 3, making any control apps expect 4 menu items not
3 !
And this example is exactly why I'm arguing against defining standard
meanings for standard controls with a menu type.
Also note that at least with the uvc driver that due to how extension
unit controls are working (the uvcvideo driver gets told about these
vendor specific controls from a userspace helper), the menu index is
the value which gets written to the hardware! So one cannot simply
make this match some random enum.
There are several advantages of sticking to one standard menu for standard
controls:
1) The contents of the menu can be defined centrally in v4l2-ctrls.c, which
ensures consistency. Not only of the menu texts, but also of how the
control behaves in various drivers.
No they cannot as v4l2-ctrls.c will not know when to return -EINVAL to
indicate that in the example case the driver does not support blink, and
moreover an app will not expect this and maybe decide to not show the
menu at all, or ...
2) It makes it possible to set the control directly from within a program.
This is currently true for *all* standard controls
No this is not true, programs still need to know minimum and maximum values
for all integer standard controls, brightness may be 0-15 on one device
and 0-65535 on another, so they cannot simply bang in any value they need to
take into account the query ctrl results.
This looks pretty decent IMHO:
enum v4l2_illuminator {
V4L2_ILLUMINATOR_OFF = 0,
V4L2_ILLUMINATOR_ON = 1,
};
#define V4L2_CID_ILLUMINATOR_0 (V4L2_CID_BASE+37)
#define V4L2_CID_ILLUMINATOR_1 (V4L2_CID_BASE+38)
I don't like this, as explained before most microscopes have a top
and a bottom light, and you want to switch between them, or to
all off, or to all on. So having a menu with 4 options for this
makes a lot more sense then having 2 separate controls. Defining
these values as standard values would take away the option for drivers
to do something other then a simple on / off control here. Again
what is wrong with with not defining standard meanings for standard
controls with a menu type. This means less stuff in videodev2.h
and more flexibility wrt using these control ids.
I think we should not even define a type for this one. If we
get microscopes with pwm control for the lights we will want this
to be an integer using one control per light.
We have this excellent infrastructure to automatically discover
control types, ranges and menu item meaning. Why would it be
forbidden to use this for standard controls.
Either we need to drop our aversion for
Re: [linux-dvb] TeVii S470 periodically fails to tune/lock - needspoweroff
Thanks for that Karsten, I have checked the temperature and seems normal . It does not look like it is getting overly hot . I have been keeping a close eye on it and it looks like I get more failures when using Diseqc . I notice when going to another satellite then coming back I seem to get more no-locks . My suspicion is that there may be some issues with diseqc function that will crash the card . After a full power down is done card is back in operation with no problems . Could this be a firmware thing ? Best Regards Milorad On Fri, Sep 3, 2010 at 6:46 PM, Karsten Siebert karsten.sieb...@transplaneta.com wrote: Check the temperature of the adapter. It is getting quite hot. I use fans to cool it, which avoids this kind of problems. -- From: OM Ugarcina mo.uc...@gmail.com Sent: Friday, September 03, 2010 10:42 AM To: linux-media@vger.kernel.org Cc: linux-...@linuxtv.org Subject: [linux-dvb] TeVii S470 periodically fails to tune/lock - needspoweroff Hello Guys, I have been using my TeVii S470 DVBS2 card for about one month . I am using it with mythtv on fedora 12 using latest kernel , and compiled the latest v4l drivers . The sensitivity and picture is very good both on dvbs and dvbs2 transponders , very happy with that . However several times already when trying to watch live tv on myth the channel failed to tune . Usually happens in the morning after box was running 24x7 for a few days . The only way to restore functionality is to do a power off and wait a couple of mins then power on . If I just do a reboot , this does not help . Strange thing is that I see nothing unusual in the mythtv logs or dmesg/messages log . When the card is in this no-lock state , it will not tune into any transponder even when I run scandvb . After power reset everything works again for a few more days . Any info welcome . Best Regards Milorad ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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] Illuminators and status LED controls
This is probably a bit OT, but these sorts of indicator LEDs can get quite
complicated.
As part of our FCamera sample program on the Nokia N900 (which uses V4L2 way
down there), we wanted to reprogram the front indicator LED to flash exactly
when a picture is taken. The N900 front LED is quite a programmable beast [1],
with a dedicated microcontroller (the lp5521) that runs little programs that
define the blink patterns for the RGB LED.
I'm not really suggesting that the V4L2 control should be able to handle this
sort of an LED, but as these sorts of things get cheaper, it may become a case
of 'why not?' for manufacturers putting in more complex RGB LEDs. And if you
don't want to encapsulate all that in V4L2, it may be better to leave it to
other APIs at some point of complexity (the current lp5521 driver seems to have
a sysfs-only interface for now for the programmable patterns, and the standard
LED API otherwise)
[1] http://wiki.maemo.org/LED_patterns
Eino-Ville Talvala
Computer Graphics Lab
Stanford University
On 9/7/2010 1:33 PM, Andy Walls wrote:
It has already been discussed. Please check the list archives for the past
few days.
Do you know of any V4L2 application developer or development team that
prefers to use a separate API just to turn lights on and off, when all other
aspects of the incoming video are controlled with the V4L2 control API?
(That question is mostly rhetorical, but I'd still actually be interested
from video app developers.)
Regards,
Andy
Eduardo Valentin eduardo.valen...@nokia.com wrote:
Hello,
On Mon, Sep 06, 2010 at 08:11:05PM +0200, ext Jean-Francois Moine wrote:
Hi,
This new proposal cancels the previous 'LED control' patch.
Cheers.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
Apologies if this has been already discussed but,
doesn't this patch duplicates the same feature present
nowadays under include/linux/leds.h ??
I mean, if you want to control leds, I think we already have that API, no?
BR,
---
Eduardo Valentin
--
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
N�r��y���b�X��ǧv�^�){.n�+{���bj)���w* jg��� �ݢj/���z�ޖ��2�ޙ)ߡ�a���� �G���h��j:+v���w�٥
--
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] Illuminators and status LED controls
On Wednesday, September 08, 2010 00:29:51 Theodore Kilgore wrote:
On Tue, 7 Sep 2010, Hans Verkuil wrote:
On Tuesday, September 07, 2010 20:42:07 Hans Verkuil wrote:
On Tuesday, September 07, 2010 19:57:18 Jean-Francois Moine wrote:
On Tue, 7 Sep 2010 17:30:33 +0200
Hans Verkuil hverk...@xs4all.nl wrote:
enum v4l2_illuminator {
V4L2_ILLUMINATOR_OFF = 0,
V4L2_ILLUMINATOR_ON = 1,
};
#define V4L2_CID_ILLUMINATOR_0 (V4L2_CID_BASE+37)
#define V4L2_CID_ILLUMINATOR_1 (V4L2_CID_BASE+38)
enum v4l2_led {
V4L2_LED_AUTO = 0,
V4L2_LED_OFF = 1,
V4L2_LED_ON = 2,
};
#define V4L2_CID_LED_0 (V4L2_CID_BASE+39)
Simple and straightforward.
Hi,
Hans (de Goede), is this OK for you? I think that if we find more
illuminators or LEDs on some devices, we may add more V4L2_CID_xxx_n
controls.
Hans (Verkuil), may we have the same enum's for both light types?
Something like:
enum v4l2_light {
V4L2_LIGHT_OFF = 0,
V4L2_LIGHT_ON = 1,
V4L2_LIGHT_AUTO = 2,
V4L2_LIGHT_BLINK = 3,
};
I'm OK with that. Although 'blink' shouldn't be added yet unless we have a
driver that will actually make use of it.
I realized something else: while for us programmers it is perfectly natural
to start counting at 0, for the rest of the world it is probably more
understandable to start counting at 1. I know it goes against our religion,
but sometimes you just have to conform. :-)
Regards,
Hans
Sorry about the long silence from here, but there has been illness in the
family. I do keep trying to watch whatever is going on.
Hans, I agree with your general characterization of the public's
perception of 0 versus 1. But on this particular occasion I suspect that
the general public would see that 0 corresponds more naturally to off
than 1 does.
Ah, I see I was ambiguous in what I wrote. I referred to the '0' in
V4L2_CID_LED_0/V4L2_CID_ILLUMINATOR_0 (and their corresponding names as
reported to the user as LED 0/Illuminator 0), not to the 0 in the enum.
Regards,
Hans
Hoping that all is well with you and others.
Cheers, and this is just my two cents on a trivial issue.
Theodore Kilgore
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] V4L/DVB: radio-si4713: Add regulator framework support
Hi On Tue, 7 Sep 2010 22:49:49 +0300 Eduardo Valentin eduardo.valen...@nokia.com wrote: Hello Jarkko, On Sun, Jun 13, 2010 at 08:09:28PM +0200, Jarkko Nikula wrote: Convert the driver to use regulator framework instead of set_power callback. This with gpio_reset platform data provide cleaner way to manage chip VIO, VDD and reset signal inside the driver. Signed-off-by: Jarkko Nikula jhnik...@gmail.com Cc: Eduardo Valentin eduardo.valen...@nokia.com --- I don't have specifications for this chip so I don't know how long the reset signal must be active after power-up. I used 50 us from Maemo kernel sources for Nokia N900 and I can successfully enable-disable transmitter on N900 with vdd power cycling. --- drivers/media/radio/radio-si4713.c | 20 ++- drivers/media/radio/si4713-i2c.c | 48 --- drivers/media/radio/si4713-i2c.h |3 +- include/media/si4713.h |3 +- Could you please elaborate a bit more on the fact that you have put vio on the platform driver and vdd on the i2c driver? This is good question and let me explain. The regulator management division between these two files were based on my assumption that only VIO is needed and must be on before probing the chip on I2C bus. Another assumption was that only VDD can realistically be managed runtime in si4713_powerup function. I think usually IO voltages cannot be shutdown even in suspend while the system is powered so I let the driver to keep the VIO enabled as long as the module is loaded. -- Jarkko -- 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
