Re: [PATCH v3 07/10] arm: omap4430sdp: Add support for omap4iss camera
Hi Sakari,
On Thu, May 3, 2012 at 7:03 AM, Aguirre, Sergio wrote:
> Hi Sakari,
>
> Thanks for reviewing.
>
> On Wed, May 2, 2012 at 2:47 PM, Sakari Ailus wrote:
>>
>> Hi Sergio,
>>
>> Thanks for the patches!!
>>
>> On Wed, May 02, 2012 at 10:15:46AM -0500, Sergio Aguirre wrote:
>> ...
>>> +static int sdp4430_ov_cam1_power(struct v4l2_subdev *subdev, int on)
>>> +{
>>> + struct device *dev = subdev->v4l2_dev->dev;
>>> + int ret;
>>> +
>>> + if (on) {
>>> + if (!regulator_is_enabled(sdp4430_cam2pwr_reg)) {
>>> + ret = regulator_enable(sdp4430_cam2pwr_reg);
>>> + if (ret) {
>>> + dev_err(dev,
>>> + "Error in enabling sensor power
>>> regulator 'cam2pwr'\n");
>>> + return ret;
>>> + }
>>> +
>>> + msleep(50);
>>> + }
>>> +
>>> + gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 1);
>>> + msleep(10);
>>> + ret = clk_enable(sdp4430_cam1_aux_clk); /* Enable XCLK */
>>> + if (ret) {
>>> + dev_err(dev,
>>> + "Error in clk_enable() in %s(%d)\n",
>>> + __func__, on);
>>> + gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
>>> + return ret;
>>> + }
>>> + msleep(10);
>>> + } else {
>>> + clk_disable(sdp4430_cam1_aux_clk);
>>> + msleep(1);
>>> + gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
>>> + if (regulator_is_enabled(sdp4430_cam2pwr_reg)) {
>>> + ret = regulator_disable(sdp4430_cam2pwr_reg);
>>> + if (ret) {
>>> + dev_err(dev,
>>> + "Error in disabling sensor power
>>> regulator 'cam2pwr'\n");
>>> + return ret;
>>> + }
>>> + }
>>> + }
>>> +
>>> + return 0;
>>> +}
>>
>> Isn't this something that should be part of the sensor driver? There's
>> nothing in the above code that would be board specific, except the names of
>> the clocks, regulators and GPIOs. The sensor driver could hold the names
>> instead; this would be also compatible with the device tree.
>
> Agreed. I see what you mean...
>
> I'll take care of that.
Can you please check out these patches?
1.
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/cb6c10d58053180364461e6bc8d30d1ec87e6e22
2.
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/6732e0db25c6647b34ef8f01c244a49a1fd6b45d
3.
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/d61c4e3142dc9cae972f9128fe73d986838c0ca1
4.
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/e83f36001c7f7cbe184ad094d9b0c95c39e5028f
I want to see if I got your point properly...
Regards,
Sergio
>
>>
>> It should be possible to have s_power() callback NULL, too.
>>
>>> +static int sdp4430_ov_cam2_power(struct v4l2_subdev *subdev, int on)
>>> +{
>>> + struct device *dev = subdev->v4l2_dev->dev;
>>> + int ret;
>>> +
>>> + if (on) {
>>> + u8 gpoctl = 0;
>>> +
>>> + ret = regulator_enable(sdp4430_cam2pwr_reg);
>>> + if (ret) {
>>> + dev_err(dev,
>>> + "Error in enabling sensor power regulator
>>> 'cam2pwr'\n");
>>> + return ret;
>>> + }
>>> +
>>> + msleep(50);
>>> +
>>> + if (twl_i2c_read_u8(TWL_MODULE_AUDIO_VOICE, &gpoctl,
>>> + TWL6040_REG_GPOCTL))
>>> + return -ENODEV;
>>> + if (twl_i2c_write_u8(TWL_MODULE_AUDIO_VOICE,
>>> + gpoctl | TWL6040_GPO3,
>>> + TWL6040_REG_GPOCTL))
>>> + return -ENODEV;
>>
>> The above piece of code looks quite interesting. What does it do?
>
> Well, this is because the camera adapter board in 4430SDP has 3
> sensors actually:
>
> - 1 Sony IMX060 12.1 MP sensor
> - 2 OmniVision OV5650 sensors
>
> And there's 3 wideband analog switches, like this:
>
> http://www.analog.com/static/imported-files/data_sheets/ADG936_936R.pdf
>
> That basically select either IMX060 or OV5650 for CSI2A input.
>
> So, this commands are because the TWL6040 chip has a GPO pin to toggle
> this, instead
> of an OMAP GPIO (Don't ask me why :) )
>
> Anyways... I see your point, maybe this should be explained better
> through a comment.
>
> Regards,
> Sergio
>>
>> Kind regards,
>>
>> --
>> Sakari Ailus
>> e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] add support for DeLOCK-USB-2.0-DVB-T-Receiver-61744
On 05/03/2012 08:17 PM, Zdenek Styblik wrote: > Hello poma, > > I'm sorry, but that's all info I've been "given". :-\ It is as it is. ;) regards, poma > On 05/03/12 09:25, poma wrote: >> >> [ …] >> >> Hi there, >> >> These two patches - 'dvb-usb-ids-v2-rtl2832-fc0012.patch' and >> 'rtl28xxu-v2-rtl2832-fc0012.patch' adds nine devices based on >> FC0012 tuner, altogether eleven. Gianluca, please inform forum >> fellows to test&reply. Zdenek, fermio - there is a note on >> http://wiki.zeratul.org/doku.php?id=linux:v4l:realtek:start at >> "Other DVB-T Sticks" regarding 'af4d:a803' device. Is it based on >> RTL2832 with FC0012 tuner? >> >> Julian, Thomas, Antii cheers mates! ;) poma >> >> ps. modinfo dvb_usb_rtl28xxu filename: >> /lib/modules/3.3.2-6.fc16.x86_64/kernel/drivers/media/dvb/dvb-usb/dvb-usb-rtl28xxu.ko >> >> > license:GPL >> author: Thomas Mair author: >> Antti Palosaari description:Realtek RTL28xxU DVB >> USB driver alias: usb:v1F4DpD803d*dc*dsc*dp*ic*isc*ip* >> alias: usb:v1F4DpC803d*dc*dsc*dp*ic*isc*ip* alias: >> usb:v1B80pD399d*dc*dsc*dp*ic*isc*ip* alias: >> usb:v1B80pD395d*dc*dsc*dp*ic*isc*ip* alias: >> usb:v1B80pD394d*dc*dsc*dp*ic*isc*ip* alias: >> usb:v1B80pD393d*dc*dsc*dp*ic*isc*ip* alias: >> usb:v1B80pD39Dd*dc*dsc*dp*ic*isc*ip* alias: >> usb:v0458p707Fd*dc*dsc*dp*ic*isc*ip* alias: >> usb:v0BDAp2838d*dc*dsc*dp*ic*isc*ip* alias: >> usb:v1F4DpB803d*dc*dsc*dp*ic*isc*ip* alias: >> usb:v0CCDp00A9d*dc*dsc*dp*ic*isc*ip* alias: >> usb:v14AAp0161d*dc*dsc*dp*ic*isc*ip* alias: >> usb:v14AAp0160d*dc*dsc*dp*ic*isc*ip* alias: >> usb:v0BDAp2831d*dc*dsc*dp*ic*isc*ip* depends: >> dvb-usb,rtl2830,rc-core vermagic: 3.3.2-6.fc16.x86_64 SMP >> mod_unload parm: debug:set debugging level (int) parm: >> adapter_nr:DVB adapter numbers (array of short) >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] add support for DeLOCK-USB-2.0-DVB-T-Receiver-61744
On 05/03/2012 11:03 AM, Gianluca Gennari wrote: > Hi poma, > I have a 0BDA:2838 (Easycap EZTV646) and a 0BDA:2832 (no name 20x20mm > mini DVB-T stick) and both are based on the E4000 tuner, which is not > supported in the kernel at the moment. > I have no idea if there are sticks with the same USB PID and the fc0012 > tuner. OK, second one - no name device is "Realtek RTL2832U reference design"**. First one: Once upon a time there was a "EasyCAP"… "After while crocodile!" …and "EzCAP" was born. http://szforwardvideo.en.alibaba.com/aboutus.html Obviously Easycap EZTV646 != EzCAP EzTV646 http://www.reddit.com/r/RTLSDR/comments/s6ddo/rtlsdr_compatibility_list_v2_work_in_progress/ ezcap EzTV646 0BDA:2838 RTL2832U/FC0012 Some revisions may have the E4000* http://i.imgur.com/mFD1X.jpg (Generic) 0BDa:2838 RTL2832U/E4000* … And, in addition: http://sdr.osmocom.org/trac/wiki/rtl-sdr 0x0bda 0x2832 all of them Generic RTL2832U (e.g. hama nano)** 0x0bda 0x2838 E4000 ezcap USB 2.0 DVB-T/DAB/FM dongle … Maybe? https://sites.google.com/site/myrtlsdr/ "EzCap EZTV646 has got RTL2832U/FC0012. However rtl-sdr must be tweaked to force FC0012 tuner because it has the same PID as EZTV668 (PID: 0x2838) so running it whithout a tweak will select Elonics E4000 tuner. Works, not so good at filtering." … Conclusion: At least two devices share same vid/pid with different tuners - fc0012 vs e4000. How to resolve this from a drivers perspective in a proper way? Beside, there is GPL'ed 'e4k' tuner source code aka 'e4000 improved'*** (Elonics E4000) by Harald Welte http://cgit.osmocom.org/cgit/osmo-sdr/tree/firmware/src/tuner_e4k.c http://sdr.osmocom.org/trac/ http://sdr.osmocom.org/trac/wiki/rtl-sdr http://wiki.spench.net/wiki/RTL2832U*** regards, poma -- 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: Hauppage HVR1600 - CX18 Issue with Centos 6.2 - Analog Sound comes and goes
On Wed, 2012-05-02 at 00:53 -0400, Bob Lightfoot wrote: > Dear Mailing List linux-media: > > I am attempting to use a Hauppage HVR-1600 purchased new in 2010 as an > analog tv tuner in my HP Pavillion Elite M9040n PC running Centos 6.2 > x86_64. The problem I am experiencing is that with every kernel update > and/or mythtv and/or vlc or other media update it seems I loose sound on > my captured avi/mpeg files. After as bit of tweaking it seems to come > back and I've never been able to pin down exactly what is hosing the > sound. I should mention the unit has an HVR 1850 at slot 2 which works > for DVB tuning jsut fine. The HVR 1600 is in pci slot 1 and from what I > can see in dmesg it also loaded fine. Maybe someone who is more > intimate with linux-media can review the data I've included and suggest > a troubleshooting approach. 1. If you ever lose sound in the ATSC or QAM DTV streams captured with the HVR-1600, then you do not have and HVR-1600 problem, you have a systems sound playback problem. In this case you must address that problem. If not, then go on to #2. 2. If you never lose sound in ATSC/QAM DTV captures, but do sometimes lose sound with MPEG captures from the analog baseband CVBS or S-Video w/ L and R audio inputs, then this is a driver problem with the CX23418's audio processing unit (APU). In this case there is are a few things to try: a. prevent the cx18-alsa.ko module from loading by removing it from your filesystem (make a back-up of the module if you wish), and reboot your computer. This will stop things like HAL and/or PulseAudio from messing with the HVR-1600 via the ALSA sound interface. b. Update to the laters cx18 driver, which will require updating many supporting media (video, dvb and common/tuner modules as well. (No guarantee this will work right on older enterprise kernels where the I2C binding model is very different from modern kernels.) c. Write a patch to the cx18 driver that has it act a little smarter about the CX23418 Capture Processing Unit (CPU) and Audio Processing Unit (APU) initialzation. Right now the processors are brought out of reset and allowed to run executing uninitialized memory as instructions before their firmware is actually loaded and the processors restarted. d. Ask me to write the patch mentioned in c. Be prepared to wait a very long time and still have to update to the latest cx18 module. If you never lose audip in MPEG captures from baseband inputs, then go to step 3. 3. If you never lose sound in ATSC/QAM DTV captures, and never lose sound with MPEG captures from the analog baseband CVBS or S-Video w/ L and R audio inputs, but you do sometimes lose audio with MPEG captures from the analog RF tuner, then the broadcast audio microcontroller in the integrated CX25843 inside the CX23418 is likely unable to identify the broadcast audio standard properly and is staying muted. If so, then a. Use 'v4l2-ctl -d /dev/videoN --log-status' to verify the audio standard is not detected and the microcontroller is muted when an analog RF capture is ongoing. b. Try installing an in-line attenuator in the RF line before it reaches the analog RF tuner input of the HVR-1600. The audio microcontroller uses spectral analysis hardware to detect the broadcast audio standard. Intermodulation products, caused by overdriving the tuner with too strong of a signal, can throw off the spectral analysis and confuse the audio standard detection microcontroller. c. Ask Mark Lord for a copy of his script/tool mentioned in this long thread: http://patchwork.linuxtv.org/patch/3162/ That periodically does some userspace actions to try and get audio back. d. Write a patch to the cx18 driver and the cx18-av-*c files specifically, that allows manual specification of audio standard to BTSC without any attaempts at auto-detection. e. Ask me to write the patch in d. Be prepared to wait a long time, etc. etc. f. See 2.c. g. See 2.d. > I am beginning to suspect I need to specify > a conf file for module cx18 but not sure where to begin that. I am > trying to maintain the package management on this system so I have not > isntalled sources or compiled anything, everything has been managed by > yum and pulled from the centos-base, centos-updates or atrpms repos for > 99% of things. There may be an elrepo or rpmfusion rpm or two, but they > would be an exception. Below I am providing what I think is the > relevant starter information. > > > uname -a ==> Linux mythbox.ladodomain 2.6.32-220.13.1.el6.x86_64 #1 SMP > Tue Apr 17 23:56:34 BST 2012 x86_64 x86_64 x86_64 GNU/Linux > > lspci output follows: > > 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM > Controller (rev 02) > 00:01.0 PCI bridge: Intel Corporation 82G33/G31/P35/P31 Express PCI > Express Root Port (rev 02) > 00:19.0 Ethernet controller: Intel Corporation 82566DC-2 Gigabit Network > Connection (rev 02) > 00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family)
Re: [RFC v3 1/2] v4l: Do not use enums in IOCTL structs
On Thu, 2012-05-03 at 07:22 -0300, Mauro Carvalho Chehab wrote:
> Em 02-05-2012 21:42, Andy Walls escreveu:
> > On Wed, 2012-05-02 at 19:17 -0300, Mauro Carvalho Chehab wrote:
> >> I suspect that sizeof() won't work inside a macro.
> >
> > sizeof() is evaluated at compile time, after preprocessing.
> > It should work inside of a macro.
>
> I tried to compile this small piece of code:
>
> enum foo { BAR };
> #if sizeof(foo) != sizeof(int)
> void main(void) { printf("different sizes\n"); }
> #else
> void main(void) { printf("same size\n"); }
> #endif
Oh, I misunderstood what you intended when you said "work inside a
macro".
You are correct. I would not expect sizeof() to work in a condition
evaluated by the preprocessor. Only the compiler can properly compute
sizeof(), after the preprocessor has done it's work -- unless someone
builds a much smarter, multiple-pass preprocessor.
> > See the ARRAY_SIZE() macro in include/linux/kernel.h for a well tested
> > example.
>
> ARRAY_SIZE() doesn't have an #if on it.
Correct. My example is irrelevant, because I didn't understand what you
meant.
Sorry for the noise.
Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: common DVB USB issues we has currently
to 3.5.2012 17:59 Brian J. Murrell kirjoitti: > On 12-05-03 10:48 AM, Devin Heitmueller wrote: >> >> I doubt this is a dvb-usb problem, but rather something specific to >> the realtek parts (suspend/resume does work with other devices that >> rely on dvb-usb). > > Dunno if it's at all relevant but I used to be able (circa 2.6.32 > perhaps? it's a bit foggy now) to suspend/resume with my HVR-950q > installed and modules loaded. Now suspending with them loaded hangs the > suspend and they can't even reliably be rmmod/modprobed pre and post > suspend/resume. > > I just wonder if that change in behavior is pointing at something. That means HVR-950q is not "DVB-USB" device OR it does not have DVB-USB-firmware to load by the DVB-USB-driver. regards Antti -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB USB issues we has currently
to 3.5.2012 18:04 Patrick Boettcher kirjoitti: > On Thursday 03 May 2012 16:20:23 Antti Palosaari wrote: >> Hello, >> Here we are, that's the first part I am going to fix as a GSoC >> project. Work is planned to start after two weeks but better to >> discuss beforehand. >> >> And wish-list is now open! >> >> I see two big DVB USB issues including multiple small issues; >> >> 1) >> Current static structure is too limited as devices are more dynamics >> nowadays. Driver should be able to probe/read from eeprom device >> configuration. >> >> Fixing all of those means rather much work - I think new version of >> DVB USB is needed. > > I'm looking forward to see RFCs about proposals for additions to dvb- > usb's structure. Especially the ugly device-usb-id-referencing. RFC is scheduled to first working week. Before that I can list all issues I am aware and I am planning to fix. Good starting point of looking problems is AF9015 driver and some other that reads device configuration from eeprom and sets config struct values. > What do you mean by "new version"? I think it is so much changes that are very hard to do for existing dvb-usb as all individual dvb-usb drivers must be changed. But that will became clear after all changes are clear and RFC is approved. Earlier I have mentioned for example availability of priv/state for first callbacks. I would like to list all all device properties, which are same for chipset, and which are only for one device model (for example remote keytable). > Also adding support for hybrid (analog+dvb-devices) is missing. Mike > Krufky did some work somewhere which looked promising but was never > merged. That was one feature what I was also thinking. But I think I don't have any such device currently - at least I have no own experience. So let's see. Also static limit for amount of individual devices in the config struct is something I would like to fix. Now it is over 10 device models, but as we have devices more than 10 it is needed to add multiple configurations. IIRC AF9015 has 3 currently. But I am now on weekend trip. I will list issues more detailed in next week. regards Antti -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] drivers/media: add missing __devexit_p() annotations
From: Arnd Bergmann
Drivers that refer to a __devexit function in an operations
structure need to annotate that pointer with __devexit_p so
replace it with a NULL pointer when the section gets discarded.
Signed-off-by: Arnd Bergmann
Signed-off-by: Mathieu Poirier
---
drivers/media/dvb/ddbridge/ddbridge-core.c |2 +-
drivers/media/radio/radio-timb.c |2 +-
drivers/media/radio/saa7706h.c |2 +-
drivers/media/radio/tef6862.c |2 +-
drivers/media/rc/imon.c|2 +-
drivers/media/rc/mceusb.c |2 +-
drivers/media/rc/redrat3.c |2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb/ddbridge/ddbridge-core.c
b/drivers/media/dvb/ddbridge/ddbridge-core.c
index d88c4aa..ef4c0f8 100644
--- a/drivers/media/dvb/ddbridge/ddbridge-core.c
+++ b/drivers/media/dvb/ddbridge/ddbridge-core.c
@@ -1696,7 +1696,7 @@ static struct pci_driver ddb_pci_driver = {
.name= "DDBridge",
.id_table= ddb_id_tbl,
.probe = ddb_probe,
- .remove = ddb_remove,
+ .remove = __devexit_p(ddb_remove),
};
static __init int module_init_ddbridge(void)
diff --git a/drivers/media/radio/radio-timb.c b/drivers/media/radio/radio-timb.c
index 5d9a90a..7052adc 100644
--- a/drivers/media/radio/radio-timb.c
+++ b/drivers/media/radio/radio-timb.c
@@ -223,7 +223,7 @@ static struct platform_driver timbradio_platform_driver = {
.owner = THIS_MODULE,
},
.probe = timbradio_probe,
- .remove = timbradio_remove,
+ .remove = __devexit_p(timbradio_remove),
};
module_platform_driver(timbradio_platform_driver);
diff --git a/drivers/media/radio/saa7706h.c b/drivers/media/radio/saa7706h.c
index 9474706..bb953ef 100644
--- a/drivers/media/radio/saa7706h.c
+++ b/drivers/media/radio/saa7706h.c
@@ -430,7 +430,7 @@ static struct i2c_driver saa7706h_driver = {
.name = DRIVER_NAME,
},
.probe = saa7706h_probe,
- .remove = saa7706h_remove,
+ .remove = __devexit_p(saa7706h_remove),
.id_table = saa7706h_id,
};
diff --git a/drivers/media/radio/tef6862.c b/drivers/media/radio/tef6862.c
index 6418c4c..06d47e5 100644
--- a/drivers/media/radio/tef6862.c
+++ b/drivers/media/radio/tef6862.c
@@ -211,7 +211,7 @@ static struct i2c_driver tef6862_driver = {
.name = DRIVER_NAME,
},
.probe = tef6862_probe,
- .remove = tef6862_remove,
+ .remove = __devexit_p(tef6862_remove),
.id_table = tef6862_id,
};
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 7f26fdf..5dd0386 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -255,7 +255,7 @@ static struct usb_device_id imon_usb_id_table[] = {
static struct usb_driver imon_driver = {
.name = MOD_NAME,
.probe = imon_probe,
- .disconnect = imon_disconnect,
+ .disconnect = __devexit_p(imon_disconnect),
.suspend= imon_suspend,
.resume = imon_resume,
.id_table = imon_usb_id_table,
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index e150a2e..845cae3 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -1443,7 +1443,7 @@ static int mceusb_dev_resume(struct usb_interface *intf)
static struct usb_driver mceusb_dev_driver = {
.name = DRIVER_NAME,
.probe =mceusb_dev_probe,
- .disconnect = mceusb_dev_disconnect,
+ .disconnect = __devexit_p(mceusb_dev_disconnect),
.suspend = mceusb_dev_suspend,
.resume = mceusb_dev_resume,
.reset_resume = mceusb_dev_resume,
diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index ad95c67..2878b0e 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -1277,7 +1277,7 @@ static int redrat3_dev_resume(struct usb_interface *intf)
static struct usb_driver redrat3_dev_driver = {
.name = DRIVER_NAME,
.probe = redrat3_dev_probe,
- .disconnect = redrat3_dev_disconnect,
+ .disconnect = __devexit_p(redrat3_dev_disconnect),
.suspend= redrat3_dev_suspend,
.resume = redrat3_dev_resume,
.reset_resume = redrat3_dev_resume,
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] media/video: add I2C dependencies
From: Arnd Bergmann Davinci VIDEO_VPFE_CAPTURE depends on I2C, so reflect that in Kconfig to avoid build failures in random configurations. Signed-off-by: Arnd Bergmann Signed-off-by: Mathieu Poirier --- drivers/media/video/davinci/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig index 60a456e..9337b56 100644 --- a/drivers/media/video/davinci/Kconfig +++ b/drivers/media/video/davinci/Kconfig @@ -40,6 +40,7 @@ config VIDEO_VPSS_SYSTEM config VIDEO_VPFE_CAPTURE tristate "VPFE Video Capture Driver" depends on VIDEO_V4L2 && (ARCH_DAVINCI || ARCH_OMAP3) + depends on I2C select VIDEOBUF_DMA_CONTIG help Support for DMx/AMx VPFE based frame grabber. This is the -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] media/rc: IR_SONY_DECODER depends on BITREVERSE
From: Arnd Bergmann The IR sony decoder is making use of 'bitrev8' that, in turn, requires BITREVERSE. Signed-off-by: Arnd Bergmann Signed-off-by: Mathieu Poirier --- drivers/media/rc/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig index a3fbb21..f97eeb8 100644 --- a/drivers/media/rc/Kconfig +++ b/drivers/media/rc/Kconfig @@ -69,6 +69,7 @@ config IR_JVC_DECODER config IR_SONY_DECODER tristate "Enable IR raw decoder for the Sony protocol" depends on RC_CORE + select BITREVERSE default y ---help--- -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] dvb/drxd: stub out drxd_attach when not built
From: Arnd Bergmann
This avoids getting
drivers/media/video/em28xx/em28xx-dvb.c:721: \
undefined reference to `drxd_attach'
Signed-off-by: Arnd Bergmann
Signed-off-by: Mathieu Poirier
---
drivers/media/dvb/frontends/drxd.h | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/frontends/drxd.h
b/drivers/media/dvb/frontends/drxd.h
index 3439873..216c8c3 100644
--- a/drivers/media/dvb/frontends/drxd.h
+++ b/drivers/media/dvb/frontends/drxd.h
@@ -51,9 +51,23 @@ struct drxd_config {
s16(*osc_deviation) (void *priv, s16 dev, int flag);
};
+#if defined(CONFIG_DVB_DRXD) || \
+ (defined(CONFIG_DVB_DRXD_MODULE) && defined(MODULE))
extern
struct dvb_frontend *drxd_attach(const struct drxd_config *config,
void *priv, struct i2c_adapter *i2c,
struct device *dev);
+#else
+static inline
+struct dvb_frontend *drxd_attach(const struct drxd_config *config,
+void *priv, struct i2c_adapter *i2c,
+struct device *dev)
+{
+ printk(KERN_INFO "%s: not probed - driver disabled by Kconfig\n",
+ __func__);
+ return NULL;
+}
+#endif
+
extern int drxd_config_i2c(struct dvb_frontend *, int);
#endif
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] video/omap24xxcam: use __iomem annotations
From: Arnd Bergmann
MMIO registers are __iomem tokens in virtual address space,
not integers.
Signed-off-by: Arnd Bergmann
Signed-off-by: Mathieu Poirier
---
drivers/media/video/omap24xxcam-dma.c | 20 ++--
drivers/media/video/omap24xxcam.c |3 +--
drivers/media/video/omap24xxcam.h | 14 +++---
3 files changed, 18 insertions(+), 19 deletions(-)
diff --git a/drivers/media/video/omap24xxcam-dma.c
b/drivers/media/video/omap24xxcam-dma.c
index 3ea38a8..b5ae170 100644
--- a/drivers/media/video/omap24xxcam-dma.c
+++ b/drivers/media/video/omap24xxcam-dma.c
@@ -38,7 +38,7 @@
*/
/* Ack all interrupt on CSR and IRQSTATUS_L0 */
-static void omap24xxcam_dmahw_ack_all(unsigned long base)
+static void omap24xxcam_dmahw_ack_all(void __iomem *base)
{
u32 csr;
int i;
@@ -52,7 +52,7 @@ static void omap24xxcam_dmahw_ack_all(unsigned long base)
}
/* Ack dmach on CSR and IRQSTATUS_L0 */
-static u32 omap24xxcam_dmahw_ack_ch(unsigned long base, int dmach)
+static u32 omap24xxcam_dmahw_ack_ch(void __iomem *base, int dmach)
{
u32 csr;
@@ -65,12 +65,12 @@ static u32 omap24xxcam_dmahw_ack_ch(unsigned long base, int
dmach)
return csr;
}
-static int omap24xxcam_dmahw_running(unsigned long base, int dmach)
+static int omap24xxcam_dmahw_running(void __iomem *base, int dmach)
{
return omap24xxcam_reg_in(base, CAMDMA_CCR(dmach)) & CAMDMA_CCR_ENABLE;
}
-static void omap24xxcam_dmahw_transfer_setup(unsigned long base, int dmach,
+static void omap24xxcam_dmahw_transfer_setup(void __iomem *base, int dmach,
dma_addr_t start, u32 len)
{
omap24xxcam_reg_out(base, CAMDMA_CCR(dmach),
@@ -112,7 +112,7 @@ static void omap24xxcam_dmahw_transfer_setup(unsigned long
base, int dmach,
| CAMDMA_CICR_DROP_IE);
}
-static void omap24xxcam_dmahw_transfer_start(unsigned long base, int dmach)
+static void omap24xxcam_dmahw_transfer_start(void __iomem *base, int dmach)
{
omap24xxcam_reg_out(base, CAMDMA_CCR(dmach),
CAMDMA_CCR_SEL_SRC_DST_SYNC
@@ -124,7 +124,7 @@ static void omap24xxcam_dmahw_transfer_start(unsigned long
base, int dmach)
| CAMDMA_CCR_SYNCHRO_CAMERA);
}
-static void omap24xxcam_dmahw_transfer_chain(unsigned long base, int dmach,
+static void omap24xxcam_dmahw_transfer_chain(void __iomem *base, int dmach,
int free_dmach)
{
int prev_dmach, ch;
@@ -160,7 +160,7 @@ static void omap24xxcam_dmahw_transfer_chain(unsigned long
base, int dmach,
* controller may not be idle after this routine completes, because
* the completion routines might start new transfers.
*/
-static void omap24xxcam_dmahw_abort_ch(unsigned long base, int dmach)
+static void omap24xxcam_dmahw_abort_ch(void __iomem *base, int dmach)
{
/* mask all interrupts from this channel */
omap24xxcam_reg_out(base, CAMDMA_CICR(dmach), 0);
@@ -171,7 +171,7 @@ static void omap24xxcam_dmahw_abort_ch(unsigned long base,
int dmach)
omap24xxcam_reg_merge(base, CAMDMA_CCR(dmach), 0, CAMDMA_CCR_ENABLE);
}
-static void omap24xxcam_dmahw_init(unsigned long base)
+static void omap24xxcam_dmahw_init(void __iomem *base)
{
omap24xxcam_reg_out(base, CAMDMA_OCP_SYSCONFIG,
CAMDMA_OCP_SYSCONFIG_MIDLEMODE_FSTANDBY
@@ -362,7 +362,7 @@ void omap24xxcam_dma_hwinit(struct omap24xxcam_dma *dma)
}
static void omap24xxcam_dma_init(struct omap24xxcam_dma *dma,
-unsigned long base)
+void __iomem *base)
{
int ch;
@@ -577,7 +577,7 @@ void omap24xxcam_sgdma_sync(struct omap24xxcam_sgdma *sgdma)
}
void omap24xxcam_sgdma_init(struct omap24xxcam_sgdma *sgdma,
- unsigned long base,
+ void __iomem *base,
void (*reset_callback)(unsigned long data),
unsigned long reset_callback_data)
{
diff --git a/drivers/media/video/omap24xxcam.c
b/drivers/media/video/omap24xxcam.c
index 7d38641..e5015b0 100644
--- a/drivers/media/video/omap24xxcam.c
+++ b/drivers/media/video/omap24xxcam.c
@@ -1776,8 +1776,7 @@ static int __devinit omap24xxcam_probe(struct
platform_device *pdev)
cam->mmio_size = resource_size(mem);
/* map the region */
- cam->mmio_base = (unsigned long)
- ioremap_nocache(cam->mmio_base_phys, cam->mmio_size);
+ cam->mmio_base = ioremap_nocache(cam->mmio_base_phys, cam->mmio_size);
if (!cam->mmio_base) {
dev_err(cam->dev, "cannot map camera register I/O region\n");
goto err;
diff --git a/drivers/media/video/omap24xxcam.h
b/drivers/media/video/omap24xxcam.h
index 2ce67f5..d59727a 100644
--- a/drivers/media/video/omap24xxcam.h
+++ b/drivers/media/video/omap24xxcam.h
@@ -429,7 +4
[PATCH 2/6] v4l/dvb: fix Kconfig dependencies on VIDEO_CAPTURE_DRIVERS
From: Arnd Bergmann Kconfig warns about unsatisfied dependencies of symbols that are directly selected. Many capture drivers depend on DVB capture drivers, which are hidden behind the CONFIG_DVB_CAPTURE_DRIVERS setting. The solution here is to enable DVB_CAPTURE_DRIVERS unconditionally when both DVB and VIDEO_CAPTURE_DRIVERS are enabled. Signed-off-by: Arnd Bergmann Signed-off-by: Mathieu Poirier --- drivers/media/dvb/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/dvb/Kconfig b/drivers/media/dvb/Kconfig index f6e40b3..c617996 100644 --- a/drivers/media/dvb/Kconfig +++ b/drivers/media/dvb/Kconfig @@ -29,7 +29,7 @@ config DVB_DYNAMIC_MINORS If you are unsure about this, say N here. menuconfig DVB_CAPTURE_DRIVERS - bool "DVB/ATSC adapters" + bool "DVB/ATSC adapters" if !VIDEO_CAPTURE_DRIVERS depends on DVB_CORE default y ---help--- -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] drivers/media: randconfig patches for kernel 3.4
From: Arnd Bergmann These patches fix miscellaneous problems when working with make randconfig. They were discovered on kernel 3.1-rc4 and have been reformatted for 3.4. Arnd Bergmann (6): drivers/media: add missing __devexit_p() annotations v4l/dvb: fix Kconfig dependencies on VIDEO_CAPTURE_DRIVERS media/rc: IR_SONY_DECODER depends on BITREVERSE media/video: add I2C dependencies dvb/drxd: stub out drxd_attach when not built video/omap24xxcam: use __iomem annotations drivers/media/dvb/Kconfig |2 +- drivers/media/dvb/ddbridge/ddbridge-core.c |2 +- drivers/media/dvb/frontends/drxd.h | 14 ++ drivers/media/radio/radio-timb.c |2 +- drivers/media/radio/saa7706h.c |2 +- drivers/media/radio/tef6862.c |2 +- drivers/media/rc/Kconfig |1 + drivers/media/rc/imon.c|2 +- drivers/media/rc/mceusb.c |2 +- drivers/media/rc/redrat3.c |2 +- drivers/media/video/davinci/Kconfig|1 + drivers/media/video/omap24xxcam-dma.c | 20 ++-- drivers/media/video/omap24xxcam.c |3 +-- drivers/media/video/omap24xxcam.h | 14 +++--- 14 files changed, 42 insertions(+), 27 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: common DVB USB issues we has currently
to 3.5.2012 20:03 Jose Alberto Reguero kirjoitti: > On Jueves, 3 de mayo de 2012 10:48:43 Devin Heitmueller escribió: >> Hi Antti, >> >> > 2) >> > Suspend/resume is not supported and crashes Kernel. I have no idea >> what is >> > wrong here and what is needed. But as it has been long term known >> problem >> > I >> > suspect it is not trivial. >> > >> > http://www.spinics.net/lists/linux-media/msg10293.html >> >> I doubt this is a dvb-usb problem, but rather something specific to >> the realtek parts (suspend/resume does work with other devices that >> rely on dvb-usb). >> >> Cheers, >> >> Devin > > I have the resume problem with the terratec H7. > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg45590.html > > Jose Alberto It crashes Kernel for every DVB USB device having DVB USB firmware. regards Antti -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] add support for DeLOCK-USB-2.0-DVB-T-Receiver-61744
Hello poma, I'm sorry, but that's all info I've been "given". :-\ Best regards, Z. On 05/03/12 09:25, poma wrote: > > [ …] > > Hi there, > > These two patches - 'dvb-usb-ids-v2-rtl2832-fc0012.patch' and > 'rtl28xxu-v2-rtl2832-fc0012.patch' adds nine devices based on > FC0012 tuner, altogether eleven. Gianluca, please inform forum > fellows to test&reply. Zdenek, fermio - there is a note on > http://wiki.zeratul.org/doku.php?id=linux:v4l:realtek:start at > "Other DVB-T Sticks" regarding 'af4d:a803' device. Is it based on > RTL2832 with FC0012 tuner? > > Julian, Thomas, Antii cheers mates! ;) poma > > ps. modinfo dvb_usb_rtl28xxu filename: > /lib/modules/3.3.2-6.fc16.x86_64/kernel/drivers/media/dvb/dvb-usb/dvb-usb-rtl28xxu.ko > > license:GPL > author: Thomas Mair author: > Antti Palosaari description:Realtek RTL28xxU DVB > USB driver alias: usb:v1F4DpD803d*dc*dsc*dp*ic*isc*ip* > alias: usb:v1F4DpC803d*dc*dsc*dp*ic*isc*ip* alias: > usb:v1B80pD399d*dc*dsc*dp*ic*isc*ip* alias: > usb:v1B80pD395d*dc*dsc*dp*ic*isc*ip* alias: > usb:v1B80pD394d*dc*dsc*dp*ic*isc*ip* alias: > usb:v1B80pD393d*dc*dsc*dp*ic*isc*ip* alias: > usb:v1B80pD39Dd*dc*dsc*dp*ic*isc*ip* alias: > usb:v0458p707Fd*dc*dsc*dp*ic*isc*ip* alias: > usb:v0BDAp2838d*dc*dsc*dp*ic*isc*ip* alias: > usb:v1F4DpB803d*dc*dsc*dp*ic*isc*ip* alias: > usb:v0CCDp00A9d*dc*dsc*dp*ic*isc*ip* alias: > usb:v14AAp0161d*dc*dsc*dp*ic*isc*ip* alias: > usb:v14AAp0160d*dc*dsc*dp*ic*isc*ip* alias: > usb:v0BDAp2831d*dc*dsc*dp*ic*isc*ip* depends: > dvb-usb,rtl2830,rc-core vermagic: 3.3.2-6.fc16.x86_64 SMP > mod_unload parm: debug:set debugging level (int) parm: > adapter_nr:DVB adapter numbers (array of short) > -- Zdenek Styblik email: sty...@turnovfree.net jabber: sty...@jabber.turnovfree.net -- 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: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Thu May 3 19:00:16 CEST 2012 git hash:bcb2cf6e0bf033d79821c89e5ccb328bfbd44907 gcc version: i686-linux-gcc (GCC) 4.6.3 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: 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-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: OK linux-3.1-i686: OK linux-3.2.1-i686: OK linux-3.3-i686: 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-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: common DVB USB issues we has currently
On Jueves, 3 de mayo de 2012 10:48:43 Devin Heitmueller escribió: > Hi Antti, > > On Thu, May 3, 2012 at 10:18 AM, Antti Palosaari > > > 1) > > Current static structure is too limited as devices are more dynamics > > nowadays. Driver should be able to probe/read from eeprom device > > configuration. > > > > Fixing all of those means rather much work - I think new version of DVB > > USB > > is needed. > > > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg44996.html > > What does this link above have to do with problem #1? Did you perhaps > cut/paste the wrong link? > > > 2) > > Suspend/resume is not supported and crashes Kernel. I have no idea what is > > wrong here and what is needed. But as it has been long term known problem > > I > > suspect it is not trivial. > > > > http://www.spinics.net/lists/linux-media/msg10293.html > > I doubt this is a dvb-usb problem, but rather something specific to > the realtek parts (suspend/resume does work with other devices that > rely on dvb-usb). > > Cheers, > > Devin I have the resume problem with the terratec H7. http://www.mail-archive.com/linux-media@vger.kernel.org/msg45590.html Jose Alberto -- 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: HVR-1600 QAM recordings with slight glitches in them
On Thu, May 3, 2012 at 12:06 PM, Brian J. Murrell wrote: > But as I mentioned before, it's now completely non-functional due to the > coax connector on the card having become loose enough to turn (with some > effort, so screwing an female F-connector on/off was still quite > doable). Perhaps it was marginal before due to that same problem. I > guess I will never know... unless I try cracking this thing open and > reconnecting whatever has gotten disconnected -- if Hauppage won't RMA > it for me. They seem to be pretty silent about that now though after an > initial e-mail exchange. If the F-connector is loose, that can *definitely* explain the problem. Let me know if you have problems getting an RMA. > If not, I've got my eye on a KWorld UB435-Q if I can determine that it's > a hardware rev. 1 unit somehow since the store doesn't want to take it > out of the box to check for me. It's less than half the price of an > HVR-950Q at $40, as much as I would love to stay loyal with Hauppage -- > this coax connector on my HVR-1600 coming loose, aside. Even if they take it out of the box, you would be unlikely to be able to determine the revision without plugging it in to something and checking the USB ID. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-1600 QAM recordings with slight glitches in them
On 12-05-03 11:37 AM, Andy Walls wrote: > Devin Heitmueller wrote: >> >> Also, which version of the HVR-1600 is this? The one with the >> mxl5005s or the tda18271? You can check the dmesg output to tell (and >> if you cannot tell, please pastebin the dmesg output so I can look). http://brian.interlinx.bc.ca/hvr-1600-dmesg > IIRC, Brian had a MXL5005s/S5H1409 variant. The latter part sounds familiar from femon and gnutv. > I think Brian might have a bad cable or connector or splitter in the run > feeding the hvr1600. The same 4-way splitter fed the HVR-950Q and the HVR-1600 and cables were swapped just about every way they could be to try to get the HVR-1600's SNR up. But as I mentioned before, it's now completely non-functional due to the coax connector on the card having become loose enough to turn (with some effort, so screwing an female F-connector on/off was still quite doable). Perhaps it was marginal before due to that same problem. I guess I will never know... unless I try cracking this thing open and reconnecting whatever has gotten disconnected -- if Hauppage won't RMA it for me. They seem to be pretty silent about that now though after an initial e-mail exchange. If not, I've got my eye on a KWorld UB435-Q if I can determine that it's a hardware rev. 1 unit somehow since the store doesn't want to take it out of the box to check for me. It's less than half the price of an HVR-950Q at $40, as much as I would love to stay loyal with Hauppage -- this coax connector on my HVR-1600 coming loose, aside. Cheers, b. signature.asc Description: OpenPGP digital signature
Re: Error compiling tw68-v2 module (module_param / linux3.2)
Hi, On Wed, May 02, 2012 at 04:32:20PM +0200, Teun wrote: > I'm having problems compiling the tw68-v2. I looked up the code from > the error messages, but I don't know anything about making linux > driver modules. > I can't find a lot about the module_param function, at least, not > why this would be wrong. > > Can anyone give any comment on this? yep, you are missing header linux/module.h. please pull again from gitorious. > Thanks in advance! no, thank you ;) cheers, Domenico -- 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: HVR-1600 QAM recordings with slight glitches in them
Devin Heitmueller wrote: >Resending with the ML back on the cc:. > >On Wed, May 2, 2012 at 11:29 PM, Brian J. Murrell > wrote: >> On 12-04-29 08:09 PM, Devin Heitmueller wrote: >>> >>> I don't know why you're not seeing valid data on femon with the >950q. >>> It should be printing out fine, and it's on the same 0.1 dB scale. >>> Try running just azap and see if the SNR is reported there. >> >> $ azap -c ~/last-channel-scan.prev 100-3 >> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' >> tuning to 65100 Hz >> video pid 0x, audio pid 0x07c1 >> status 00 | signal | snr | ber | unc | >> status 1f | signal | snr 0190 | ber | unc | >FE_HAS_LOCK >> status 1f | signal 0190 | snr 0190 | ber | unc | >FE_HAS_LOCK >> status 1f | signal 0190 | snr | ber | unc | >FE_HAS_LOCK >> status 1f | signal 0190 | snr | ber | unc | >FE_HAS_LOCK >> status 1f | signal | snr 0190 | ber | unc | >FE_HAS_LOCK >> status 1f | signal | snr 0190 | ber | unc | >FE_HAS_LOCK >> status 1f | signal 0190 | snr 0190 | ber | unc | >FE_HAS_LOCK >> status 1f | signal | snr 0190 | ber | unc | >FE_HAS_LOCK >> status 1f | signal 0190 | snr | ber | unc | >FE_HAS_LOCK >> status 1f | signal 0190 | snr | ber | unc | >FE_HAS_LOCK >> status 1f | signal 0190 | snr 0190 | ber | unc | >FE_HAS_LOCK >> status 1f | signal 0190 | snr 0190 | ber | unc | >FE_HAS_LOCK >> status 1f | signal 0190 | snr | ber | unc | >FE_HAS_LOCK >> status 1f | signal | snr 0190 | ber | unc | >FE_HAS_LOCK >> ... >> >> Doesn't seem to be useful values. > >That actually is useful data. The SNR of 0x190 means 40.0 dB (which >is a max good signal). The fact that it sometimes goes between 0x190 >and 0x000 is actually a bug in the driver I discovered a couple of >months ago but haven't submitted a patch for. In fact it's strong >enough that you might actually be over driving the tuner and may wish >to try an attenuator. > >This suggests the signal is fine (although I would probably run it for >longer and make sure you don't see intermittent UNC conditions). And >you're using the exact same cabling for the 1600 as you are for the >950q above? > >Also, which version of the HVR-1600 is this? The one with the >mxl5005s or the tda18271? You can check the dmesg output to tell (and >if you cannot tell, please pastebin the dmesg output so I can look). > >Devin > >-- >Devin J. Heitmueller - Kernel Labs >http://www.kernellabs.com >-- >To unsubscribe from this list: send the line "unsubscribe linux-media" >in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html IIRC, Brian had a MXL5005s/S5H1409 variant. I think Brian might have a bad cable or connector or splitter in the run feeding the hvr1600. Just a guess... Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB USB issues we has currently
On Thursday 03 May 2012 16:20:23 Antti Palosaari wrote: > Hello, > Here we are, that's the first part I am going to fix as a GSoC > project. Work is planned to start after two weeks but better to > discuss beforehand. > > And wish-list is now open! > > I see two big DVB USB issues including multiple small issues; > > 1) > Current static structure is too limited as devices are more dynamics > nowadays. Driver should be able to probe/read from eeprom device > configuration. > > Fixing all of those means rather much work - I think new version of > DVB USB is needed. I'm looking forward to see RFCs about proposals for additions to dvb- usb's structure. Especially the ugly device-usb-id-referencing. What do you mean by "new version"? > 2) > Suspend/resume is not supported and crashes Kernel. I have no idea > what is wrong here and what is needed. But as it has been long term > known problem I suspect it is not trivial. Are you sure that suspend/resume-crashes are related to dvb-usb? Maybe the refactoring of some buffer-handling should be considered. Also adding support for hybrid (analog+dvb-devices) is missing. Mike Krufky did some work somewhere which looked promising but was never merged. best regards, -- 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: common DVB USB issues we has currently
On 12-05-03 10:48 AM, Devin Heitmueller wrote: > > I doubt this is a dvb-usb problem, but rather something specific to > the realtek parts (suspend/resume does work with other devices that > rely on dvb-usb). Dunno if it's at all relevant but I used to be able (circa 2.6.32 perhaps? it's a bit foggy now) to suspend/resume with my HVR-950q installed and modules loaded. Now suspending with them loaded hangs the suspend and they can't even reliably be rmmod/modprobed pre and post suspend/resume. I just wonder if that change in behavior is pointing at something. Cheers, b. signature.asc Description: OpenPGP digital signature
Re: common DVB USB issues we has currently
Hi Antti, On Thu, May 3, 2012 at 10:18 AM, Antti Palosaari > 1) > Current static structure is too limited as devices are more dynamics > nowadays. Driver should be able to probe/read from eeprom device > configuration. > > Fixing all of those means rather much work - I think new version of DVB USB > is needed. > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg44996.html What does this link above have to do with problem #1? Did you perhaps cut/paste the wrong link? > 2) > Suspend/resume is not supported and crashes Kernel. I have no idea what is > wrong here and what is needed. But as it has been long term known problem I > suspect it is not trivial. > > http://www.spinics.net/lists/linux-media/msg10293.html I doubt this is a dvb-usb problem, but rather something specific to the realtek parts (suspend/resume does work with other devices that rely on dvb-usb). Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
common DVB USB issues we has currently
Hello, Here we are, that's the first part I am going to fix as a GSoC project. Work is planned to start after two weeks but better to discuss beforehand. And wish-list is now open! I see two big DVB USB issues including multiple small issues; 1) Current static structure is too limited as devices are more dynamics nowadays. Driver should be able to probe/read from eeprom device configuration. Fixing all of those means rather much work - I think new version of DVB USB is needed. http://www.mail-archive.com/linux-media@vger.kernel.org/msg44996.html 2) Suspend/resume is not supported and crashes Kernel. I have no idea what is wrong here and what is needed. But as it has been long term known problem I suspect it is not trivial. http://www.spinics.net/lists/linux-media/msg10293.html regards Antti -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] az6007: Fix dubious use of !x & y
The intent here must be to check if the right most bit
of msgs[i].flags is set and then do the logical negation.
Used macro:
#define I2C_M_RD0x0001
Sparse warns about this:
drivers/media/dvb/dvb-usb/az6007.c:714:40:
warning: dubious: !x & y
Signed-off-by: Emil Goode
---
drivers/media/dvb/dvb-usb/az6007.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb/dvb-usb/az6007.c
b/drivers/media/dvb/dvb-usb/az6007.c
index 4008b9c..0019335a 100644
--- a/drivers/media/dvb/dvb-usb/az6007.c
+++ b/drivers/media/dvb/dvb-usb/az6007.c
@@ -711,7 +711,7 @@ static int az6007_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg msgs[],
addr = msgs[i].addr << 1;
if (((i + 1) < num)
&& (msgs[i].len == 1)
- && (!msgs[i].flags & I2C_M_RD)
+ && !(msgs[i].flags & I2C_M_RD)
&& (msgs[i + 1].flags & I2C_M_RD)
&& (msgs[i].addr == msgs[i + 1].addr)) {
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UVCvideo: Failed to resubmit video URB (-27) with Linux 3.3.3
On Wed, 02 May 2012 14:24:11 +0200, Laurent Pinchart wrote : > Hi Anisse, > > On Thursday 26 April 2012 20:07:21 Anisse Astier wrote: > > Hi, > > > > I'm experiencing a problem with uvcvideo with kernel 3.3.3 and today's > > Linus' tree. > > > > Problem not reproduced in 3.2.15, so this could be labelled as a regression. > > > > See webcam lsusb and (verbose!) dmesg log in attachment, which exhibits > > the problem. > > > > We see lots of error (-18 = -EXDEV), that indicate that URB was too late > > and then dropped, and they add up until we reach the "Failed to resubmit > > video URB" scheduling issue. > > Those are USB controller issues. The uvcvideo driver submits URBs with the > URB_ISO_ASAP transfer flag, so the controller should not fail to schedule > them. Yes, it's weird. So I followed Oleksij's adviced and reverted the following commit groups: - 66847ef [media] uvcvideo: Add UVC timestamps support, 3afedb9 [media] uvcvideo: Don't skip erroneous payloads and ed0ee0c [media] uvcvideo: Fix race-related crash in uvc_video_clock_update() - ab86e9e [media] uvcvideo: Allow userptr IO mode and 6998b6f [media] uvcvideo: Use videobuf2-vmalloc - 3d95e93 [media] uvcvideo: Move fields from uvc_buffer::buf to uvc_buffer - c4d99f8 [media] uvcvideo: Ignore GET_RES error for XU controls - 806e23e [media] uvcvideo: Fix integer overflow in uvc_ioctl_ctrl_map() - d0d9748 [media] uvcvideo: Use kcalloc instead of kzalloc to allocate array None of this fixed the issue. So I just decided to revert the whole uvc driver: git checkout v3.2 -- drivers/media/video/uvc. But, the problem was still here. I reverted the usb host code in drivers/usb/host/. Again the problem was reproduced (both with and without 3.2's uvcvideo driver) Then I tested the whole kernel v3.2, and indeed it still works very well. So this problem could have it's root in USB core changes, or even a combilation of USB and UVC changes. > > > Installed libv4l version is 0.8.6. > > I'm reproducing this with: gst-launch-0.10 --verbose v4l2src ! xvimagesink > > (Skype exhibits the problem too, while it isn't using gstreamer, so it > > really seems to come from kernel. Also, doesn't happen with 3.2) > > > > This is the first part of the problem. The second part is that if I > > restart the webcam with gst-launch after the first failure, I have a > > total freeze, just after these messages in the log (fetched with > > netconsole, I wasn't able to get a panic trace): > > > > [ 191.796217] uvcvideo: Marking buffer as bad (error bit set). > > [ 191.796233] uvcvideo: Marking buffer as bad (error bit set). > > [ 191.796244] uvcvideo: Marking buffer as bad (error bit set). > > [ 191.796252] uvcvideo: Marking buffer as bad (error bit set). > > [ 191.796259] uvcvideo: Frame complete (EOF found). > > [ 191.796265] uvcvideo: EOF in empty payload. > > [ 192.972803] uvcvideo: Marking buffer as bad (error bit set). > > [ 192.972818] uvcvideo: Dropping payload (out of sync). > > [ 194.289463] uvcvideo: Marking buffer as bad (error bit set). > > [ 194.289478] uvcvideo: Frame complete (FID bit toggled). > > [ 194.289486] uvcvideo: Marking buffer as bad (error bit set). > > [ 194.289493] uvcvideo: Frame complete (FID bit toggled). > > [ 194.289499] uvcvideo: Marking buffer as bad (error bit set). > > [ 194.289505] uvcvideo: Frame complete (FID bit toggled). > > [ 194.289511] uvcvideo: Marking buffer as bad (error bit set). > > [ 194.289518] uvcvideo: Frame complete (FID bit toggled). > > [ 194.289524] uvcvideo: Marking buffer as bad (error bit set). > > [ 194.289531] uvcvideo: Frame complete (FID bit toggled). > > > > Last but not least, uvcvideo is un-bisectable because there were a few > > crash-fixes during the 3.3 development cycle. I started bisecting and got > > kernel panics. > > Are the kernel panics related to uvcvideo ? There's one known bug introduced > between v3.2 and v3.3 and fixed (before v3.3) in commit > 8e57dec0454d8a3ba987d18b3ab19922c766d4bc. I don't think that's it. As I've said, problem exists with both 3.3.3 and Linus' 3.4-rc5. -- Anisse -- 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 USB issues we has currently
Hello, Here we are, that's the first part I am going to fix as a GSoC project. Work is planned to start after two weeks but better to discuss beforehand. And wish-list is now open! I see two big DVB USB issues including multiple small issues; 1) Current static structure is too limited as devices are more dynamics nowadays. Driver should be able to probe/read from eeprom device configuration. Fixing all of those means rather much work - I think new version of DVB USB is needed. http://www.mail-archive.com/linux-media@vger.kernel.org/msg44996.html 2) Suspend/resume is not supported and crashes Kernel. I have no idea what is wrong here and what is needed. But as it has been long term known problem I suspect it is not trivial. http://www.spinics.net/lists/linux-media/msg10293.html regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: logitech quickcam 9000 uvcdynctrl broken since kernel 3.2 - PING
Karl Hi, I'm setting up a libwebcam git repo in sourceforge, Martin Rubli from logitech (the libwebcam developer), was kind enough to post me all it's code and the old svn repo backup. He had already done some fixes regarding the new ioctls for version 0.3, so I just need to go through that and add add them to 0.2. I still need to check with him how he wants to handle the 0.3 version, since it has a lot of new code ( and some extra apps ). Regards, Paulo 2012/5/3 Karl Kiniger : > Hi Paulo, > > On Wed 120502, Paulo Assis wrote: >> OK, so UVCIOC_CTRL_ADD is no longer available, now we have: >> >> UVCIOC_CTRL_MAP and UVCIOC_CTRL_QUERY, so I guess some changes are >> needed, I'll try to fix this ASAP. > > compiled libwebcam-0.2.1 from Ubuntu (had to fight against > CMake - I am almost CMake agnostic so far...) and I got the > manual focus control in guvcview so things are definitely > looking better now. > > So far I have got a focus slider and a LED1 frequency slider, > but not a LED mode... forgot what exactly was available in > the past. > > --- > LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/uvcdynctrl -i > /usr/share/uvcdynctrl/data/046d/logitech.xml > [libwebcam] Unsupported V4L2_CID_EXPOSURE_AUTO control with a non-contiguous > range of choice IDs found > [libwebcam] Invalid or unsupported V4L2 control encountered: ctrl_id = > 0x009A0901, name = 'Exposure, Auto' > Importing dynamic controls from file > /usr/share/uvcdynctrl/data/046d/logitech.xml. > /usr/share/uvcdynctrl/data/046d/logitech.xml: error: video0: unable to > map 'Pan (relative)' control. ioctl(UVCIOC_CTRL_MAP) failed with return > value -1 (error 2: No such file or directory) > /usr/share/uvcdynctrl/data/046d/logitech.xml: error: video0: unable to map > 'Tilt (relative)' > control. ioctl(UVCIOC_CTRL_MAP) failed with return value -1 (error 2: No > such file or directory) > /usr/share/uvcdynctrl/data/046d/logitech.xml:354: error: Invalid V4L2 control > type specified: 'V4L2_CTRL_TYPE_BUTTON' > /usr/share/uvcdynctrl/data/046d/logitech.xml:368: error: Invalid V4L2 control > type specified: 'V4L2_CTRL_TYPE_BUTTON' > /usr/share/uvcdynctrl/data/046d/logitech.xml:396: error: Invalid V4L2 control > type specified: 'V4L2_CTRL_TYPE_MENU' > > Thanks again, > Karl > >> >> Regards, >> Paulo > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 1/2] v4l: Do not use enums in IOCTL structs
On Thursday 03 May 2012 15:42:46 Mauro Carvalho Chehab wrote: > Em 03-05-2012 04:02, Hans Verkuil escreveu: > > On Wed May 2 2012 23:39:15 Sakari Ailus wrote: > >> Hi Hans, > >> > >> On Wed, May 02, 2012 at 10:45:22PM +0200, Hans Verkuil wrote: > >>> On Wed May 2 2012 21:13:47 Sakari Ailus wrote: > Replace enums in IOCTL structs by __u32. The size of enums is variable > and > thus problematic. Compatibility structs having exactly the same as > original > definition are provided for compatibility with old binaries with the > required conversion code. > >>> > >>> Does someone actually have hard proof that there really is a problem? You > >>> know, > >>> demonstrate it with actual example code? > >>> > >>> It's pretty horrible that you have to do all those conversions and that > >>> code > >>> will be with us for years to come. > >>> > >>> For most (if not all!) architectures sizeof(enum) == sizeof(u32), so > >>> there is > >>> no need for any compat code for those. > >> > >> Cases I know where this can go wrong are, but there may well be others: > >> > >> - ppc64: int is 64 bits there, and thus also enums, > > > > Are you really, really certain that's the case? If I look at > > arch/powerpc/include/asm/types.h it includes either asm-generic/int-l64.h > > or asm-generic/int-ll64.h and both of those headers define u32 as unsigned > > int. > > Also, if sizeof(int) != 4, then how would you define u32? > > > > Ask a ppc64 kernel maintainer what sizeof(int) and sizeof(enum) are in the > > kernel > > before we start doing lots of work for no reason. > > > > Looking at arch/*/include/asm/types.h it seems all architectures define > > sizeof(int) > > as 4. > > > > What sizeof(long) is will actually differ between architectures, but char, > > short > > and int seem to be fixed everywhere. > > Yes, it seems that, inside the Kernel, "int" it will always be 32 bits. It > doesn't > necessarily means that "enum" will be 32 bits. Actually, I believe it is. It is my understanding that --short-enums is not allowed inside the kernel and so enums are the same size as int. But I'd like to have some confirmation about that first. That compiler option isn't used anywhere in the kernel in any case and gcc on ARM will default to int-sized enums on linux. So just changing all the enums in videodev2.h to u32 should almost certainly be all we need to do. > Also, as it is recommended to not use "int/unsigned int/long/unsigned long" > at > kernel<->userspace API, I bet that this will cause problems on userspace > (maybe > with non-gcc compilers?) 'long' is certainly known to change size depending on the compiler. 'int' can be two bytes on *really* old hardware/compilers. struct v4l2_jpegcompression is the only place where int is still used. I wouldn't mind if that changes to u32 at the same time (those ints should have been unsigned anyway). 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
GSoC 2012 Linux-Media!
Moikka! As I have mentioned many people already, I have got Google Summer of Code project for the Linux-Media! It means I can do three months full time work starting from the week 21 (21.05.2012). Originally I applied "Open firmware for ath9k_htc" -project as that was listed but I added own topic for Linux-Media related stuff and it was accepted. It is rather much time I can spend and fix all those problems I have seen during recent years. Schedule is first to fix all DVB USB problems and then move to enhancing DVB CORE / frontend. I planned only general digital television stuff since it is what I know best. But if there is some time I can likely do some other general fixes. Here is short description. http://www.google-melange.com/gsoc/project/google/gsoc2012/crope/10001 I will open another thread just discussing what are the most important things and how those should be fixed "correctly". And there is no blog yet, but sometime ago I created LinuxTV page for Google+. Lets use it: https://plus.google.com/u/0/11135056277089175/posts And my mentor is Hin-Tak Leung. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 1/2] v4l: Do not use enums in IOCTL structs
Em 03-05-2012 04:02, Hans Verkuil escreveu: > On Wed May 2 2012 23:39:15 Sakari Ailus wrote: >> Hi Hans, >> >> On Wed, May 02, 2012 at 10:45:22PM +0200, Hans Verkuil wrote: >>> On Wed May 2 2012 21:13:47 Sakari Ailus wrote: Replace enums in IOCTL structs by __u32. The size of enums is variable and thus problematic. Compatibility structs having exactly the same as original definition are provided for compatibility with old binaries with the required conversion code. >>> >>> Does someone actually have hard proof that there really is a problem? You >>> know, >>> demonstrate it with actual example code? >>> >>> It's pretty horrible that you have to do all those conversions and that code >>> will be with us for years to come. >>> >>> For most (if not all!) architectures sizeof(enum) == sizeof(u32), so there >>> is >>> no need for any compat code for those. >> >> Cases I know where this can go wrong are, but there may well be others: >> >> - ppc64: int is 64 bits there, and thus also enums, > > Are you really, really certain that's the case? If I look at > arch/powerpc/include/asm/types.h it includes either asm-generic/int-l64.h > or asm-generic/int-ll64.h and both of those headers define u32 as unsigned > int. > Also, if sizeof(int) != 4, then how would you define u32? > > Ask a ppc64 kernel maintainer what sizeof(int) and sizeof(enum) are in the > kernel > before we start doing lots of work for no reason. > > Looking at arch/*/include/asm/types.h it seems all architectures define > sizeof(int) > as 4. > > What sizeof(long) is will actually differ between architectures, but char, > short > and int seem to be fixed everywhere. Yes, it seems that, inside the Kernel, "int" it will always be 32 bits. It doesn't necessarily means that "enum" will be 32 bits. Also, as it is recommended to not use "int/unsigned int/long/unsigned long" at kernel<->userspace API, I bet that this will cause problems on userspace (maybe with non-gcc compilers?) Regards, Mauro [PATCH] edac: Change internal representation to work with layers Change the EDAC internal representation to work with non-csrow based memory controllers. There are lots of those memory controllers nowadays, and more are coming. So, the EDAC internal representation needs to be changed, in order to work with those memory controllers, while preserving backward compatibility with the old ones. The edac core was written with the idea that memory controllers are able to directly access csrows. This is not true for FB-DIMM and RAMBUS memory controllers. Also, some recent advanced memory controllers don't present a per-csrows view. Instead, they view memories as DIMMs, instead of ranks. So, change the allocation and error report routines to allow them to work with all types of architectures. This will allow the removal of several hacks with FB-DIMM and RAMBUS memory controllers. Also, several tests were done on different platforms using different x86 drivers. TODO: a multi-rank DIMMs are currently represented by multiple DIMM entries in struct dimm_info. That means that changing a label for one rank won't change the same label for the other ranks at the same DIMM. This bug is present since the beginning of the EDAC, so it is not a big deal. However, on several drivers, it is possible to fix this issue, but it should be a per-driver fix, as the csrow => DIMM arrangement may not be equal for all. So, don't try to fix it here yet. I tried to make this patch as short as possible, preceding it with several other patches that simplified the logic here. Yet, as the internal API changes, all drivers need changes. The changes are generally bigger in the drivers for FB-DIMMs. Cc: Aristeu Rozanski Cc: Doug Thompson Cc: Borislav Petkov Cc: Mark Gross Cc: Jason Uhlenkott Cc: Tim Small Cc: Ranganathan Desikan Cc: "Arvind R." Cc: Olof Johansson Cc: Egor Martovetsky Cc: Chris Metcalf Cc: Michal Marek Cc: Jiri Kosina Cc: Joe Perches Cc: Dmitry Eremin-Solenikov Cc: Benjamin Herrenschmidt Cc: Hitoshi Mitake Cc: Andrew Morton Cc: "Niklas Söderlund" Cc: Shaohui Xie Cc: Josh Boyer Cc: linuxppc-...@lists.ozlabs.org Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/edac/edac_core.h b/drivers/edac/edac_core.h index e48ab31..1286c5e 100644 --- a/drivers/edac/edac_core.h +++ b/drivers/edac/edac_core.h @@ -447,8 +447,12 @@ static inline void pci_write_bits32(struct pci_dev *pdev, int offset, #endif /* CONFIG_PCI */ -extern struct mem_ctl_info *edac_mc_alloc(unsigned sz_pvt, unsigned nr_csrows, - unsigned nr_chans, int edac_index); +struct mem_ctl_info *edac_mc_alloc(unsigned sz_pvt, unsigned nr_csrows, + unsigned nr_chans, int edac_index); +struct mem_ctl_info *new_edac_mc_alloc(unsigned edac_index, + unsigned n_layers, + struct edac_mc_layer *layers, +
Re: [RFC v3 2/2] v4l: Implement compat functions for enum to __u32 change
Em 02-05-2012 20:38, Laurent Pinchart escreveu:
> Hi Mauro,
>
> On Wednesday 02 May 2012 19:32:23 Mauro Carvalho Chehab wrote:
>> Em 02-05-2012 16:13, Sakari Ailus escreveu:
>>> Implement compat functions to provide conversion between structs
>>> containing enums and those not. The functions are intended to be removed
>>> when the support for such old binaries is no longer necessary.
>>
>> This is not a full review of this patch, as checking the full logic
>> will consume some time.
>>
>> This is just a few points to consider.
>
> [snip]
>
>>> -video_usercopy(struct file *file, unsigned int cmd, unsigned long arg,
>>> +video_usercopy(struct file *file, unsigned int compat_cmd, unsigned long
>>> arg,>
>>>v4l2_kioctl func)
>>>
>>> {
>>>
>>> charsbuf[128];
>>>
>>> @@ -2401,6 +3048,7 @@ video_usercopy(struct file *file, unsigned int cmd,
>>> unsigned long arg,>
>>> size_t array_size = 0;
>>> void __user *user_ptr = NULL;
>>> void**kernel_ptr = NULL;
>>>
>>> + unsigned int cmd = get_non_compat_cmd(compat_cmd);
>>
>> This will put a penalty on archs where sizeof(u32) == sizeof(enum), with
>> covers most of the cases.
>>
>> My suggestion is to, instead, call it at the end of __video_do_ioctl, at
>> the "default" clause, with a recursive call to __video_do_ioctl().
>
> Would that work for "has_array_args" ioctls ? video_usercopy() won't copy the
> array. The compat code could possibly handle that though.
>
> What about making get_non_compat_cmd() return its argument directly when
> sizeof(__u32) == sizeof(enum) ? The performance impact should be negligible.
Good idea. GCC optimizer will probably just discard the entire code, by merging
'compat_cmd' var with 'cmd' var.
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 1/2] v4l: Do not use enums in IOCTL structs
Rémi Denis-Courmont wrote: Answering myself. On Thu, 03 May 2012 12:57:00 +0200, Rémi Denis-Courmont wrote: On Thu, 3 May 2012 00:39:15 +0300, Sakari Ailus wrote: - ppc64: int is 64 bits there, and thus also enums, Really? No, really not: http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUND-TYPE Right. Someone brought that up AFAIR and I didn't check it from other sources. Thanks for the correction. -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-1600 QAM recordings with slight glitches in them
Resending with the ML back on the cc:. On Wed, May 2, 2012 at 11:29 PM, Brian J. Murrell wrote: > On 12-04-29 08:09 PM, Devin Heitmueller wrote: >> >> I don't know why you're not seeing valid data on femon with the 950q. >> It should be printing out fine, and it's on the same 0.1 dB scale. >> Try running just azap and see if the SNR is reported there. > > $ azap -c ~/last-channel-scan.prev 100-3 > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > tuning to 65100 Hz > video pid 0x, audio pid 0x07c1 > status 00 | signal | snr | ber | unc | > status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK > status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK > status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK > status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK > status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK > status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK > status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK > status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK > status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK > status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK > status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK > status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK > status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK > status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK > ... > > Doesn't seem to be useful values. That actually is useful data. The SNR of 0x190 means 40.0 dB (which is a max good signal). The fact that it sometimes goes between 0x190 and 0x000 is actually a bug in the driver I discovered a couple of months ago but haven't submitted a patch for. In fact it's strong enough that you might actually be over driving the tuner and may wish to try an attenuator. This suggests the signal is fine (although I would probably run it for longer and make sure you don't see intermittent UNC conditions). And you're using the exact same cabling for the 1600 as you are for the 950q above? Also, which version of the HVR-1600 is this? The one with the mxl5005s or the tda18271? You can check the dmesg output to tell (and if you cannot tell, please pastebin the dmesg output so I can look). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-1600 QAM recordings with slight glitches in them
Oh, and as Andy suggested, please provide a sample of the azap or femon output for the HVR-1600 where you don't grep out the lines, so we can see what the SNR looks like before and after the point in time when the uncorrectable errors occurred. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 1/2] v4l: Do not use enums in IOCTL structs
Em 03-05-2012 07:35, Sakari Ailus escreveu:
> Hi Mauro,
>
> Mauro Carvalho Chehab wrote:
>> Em 02-05-2012 21:42, Andy Walls escreveu:
>>> On Wed, 2012-05-02 at 19:17 -0300, Mauro Carvalho Chehab wrote:
>>>
We can speed-up the conversions, with something like:
enum foo {
BAR
};
if (sizeof(foo) != sizeof(u32))
call_compat_logic().
I suspect that sizeof() won't work inside a macro.
>>>
>>> sizeof() is evaluated at compile time, after preprocessing.
>>> It should work inside of a macro.
>>
>> I tried to compile this small piece of code:
>>
>> enum foo { BAR };
>> #if sizeof(foo) != sizeof(int)
>> void main(void) { printf("different sizes\n"); }
>> #else
>> void main(void) { printf("same size\n"); }
>> #endif
>>
>> It gives an error:
>>
>> /tmp/foo.c:2:11: error: missing binary operator before token "("
>>
>> So, either this doesn't work, because sizeof() is evaluated too late,
>> or some trick is needed.
>>
>> Weird enough, cpp generates the error, but the expression is well-evaluated:
>>
>> $ cpp /tmp/foo.c
>> # 1 "/tmp/foo.c"
>> # 1 ""
>> # 1 ""
>> # 1 "/tmp/foo.c"
>> /tmp/foo.c:2:11: error: missing binary operator before token "("
>> enum foo { BAR };
>
> sizeof() is processed by C compiler while #if is preprocessor directive, and
> its arguments have to be evaluable by the preprocessor, which is the problem
> here.
>
> The C compiler can also optimise away things like that but it's more
> difficult to see whether that takes place or not; one would need to look at
> the resulting assembly code.
This code:
void main(void) {
if (sizeof(int) == sizeof(char))
printf("same size\n");
else
printf("different sizes\n");
}
should be evaluated by the compiler as if (0) and should not generate any code.
The assembler for it is:
.file "foo.c"
.section.rodata
.LC0:
.string "different sizes"
.text
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movl$.LC0, %edi
callputs
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size main, .-main
.ident "GCC: (GNU) 4.6.3 20120306 (Red Hat 4.6.3-2)"
.section.note.GNU-stack,"",@progbits
So, gcc will remove the dead code, as expected.
So, the trick is to do something similar to that on the compat code, in order
to avoid any penalties when sizeof(enum) is 32 bits.
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 07/10] arm: omap4430sdp: Add support for omap4iss camera
Hi Sakari,
Thanks for reviewing.
On Wed, May 2, 2012 at 2:47 PM, Sakari Ailus wrote:
>
> Hi Sergio,
>
> Thanks for the patches!!
>
> On Wed, May 02, 2012 at 10:15:46AM -0500, Sergio Aguirre wrote:
> ...
>> +static int sdp4430_ov_cam1_power(struct v4l2_subdev *subdev, int on)
>> +{
>> + struct device *dev = subdev->v4l2_dev->dev;
>> + int ret;
>> +
>> + if (on) {
>> + if (!regulator_is_enabled(sdp4430_cam2pwr_reg)) {
>> + ret = regulator_enable(sdp4430_cam2pwr_reg);
>> + if (ret) {
>> + dev_err(dev,
>> + "Error in enabling sensor power
>> regulator 'cam2pwr'\n");
>> + return ret;
>> + }
>> +
>> + msleep(50);
>> + }
>> +
>> + gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 1);
>> + msleep(10);
>> + ret = clk_enable(sdp4430_cam1_aux_clk); /* Enable XCLK */
>> + if (ret) {
>> + dev_err(dev,
>> + "Error in clk_enable() in %s(%d)\n",
>> + __func__, on);
>> + gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
>> + return ret;
>> + }
>> + msleep(10);
>> + } else {
>> + clk_disable(sdp4430_cam1_aux_clk);
>> + msleep(1);
>> + gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
>> + if (regulator_is_enabled(sdp4430_cam2pwr_reg)) {
>> + ret = regulator_disable(sdp4430_cam2pwr_reg);
>> + if (ret) {
>> + dev_err(dev,
>> + "Error in disabling sensor power
>> regulator 'cam2pwr'\n");
>> + return ret;
>> + }
>> + }
>> + }
>> +
>> + return 0;
>> +}
>
> Isn't this something that should be part of the sensor driver? There's
> nothing in the above code that would be board specific, except the names of
> the clocks, regulators and GPIOs. The sensor driver could hold the names
> instead; this would be also compatible with the device tree.
Agreed. I see what you mean...
I'll take care of that.
>
> It should be possible to have s_power() callback NULL, too.
>
>> +static int sdp4430_ov_cam2_power(struct v4l2_subdev *subdev, int on)
>> +{
>> + struct device *dev = subdev->v4l2_dev->dev;
>> + int ret;
>> +
>> + if (on) {
>> + u8 gpoctl = 0;
>> +
>> + ret = regulator_enable(sdp4430_cam2pwr_reg);
>> + if (ret) {
>> + dev_err(dev,
>> + "Error in enabling sensor power regulator
>> 'cam2pwr'\n");
>> + return ret;
>> + }
>> +
>> + msleep(50);
>> +
>> + if (twl_i2c_read_u8(TWL_MODULE_AUDIO_VOICE, &gpoctl,
>> + TWL6040_REG_GPOCTL))
>> + return -ENODEV;
>> + if (twl_i2c_write_u8(TWL_MODULE_AUDIO_VOICE,
>> + gpoctl | TWL6040_GPO3,
>> + TWL6040_REG_GPOCTL))
>> + return -ENODEV;
>
> The above piece of code looks quite interesting. What does it do?
Well, this is because the camera adapter board in 4430SDP has 3
sensors actually:
- 1 Sony IMX060 12.1 MP sensor
- 2 OmniVision OV5650 sensors
And there's 3 wideband analog switches, like this:
http://www.analog.com/static/imported-files/data_sheets/ADG936_936R.pdf
That basically select either IMX060 or OV5650 for CSI2A input.
So, this commands are because the TWL6040 chip has a GPO pin to toggle
this, instead
of an OMAP GPIO (Don't ask me why :) )
Anyways... I see your point, maybe this should be explained better
through a comment.
Regards,
Sergio
>
> Kind regards,
>
> --
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
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
[RESEND GIT PULL] git://linuxtv.org/mkrufky/hauppauge.git windham-ids
On Thu, Mar 22, 2012 at 1:00 PM, Michael Krufky wrote: > Mauro, > > Please merge this small patch for a USB ID addition Mauro, I do not believe this ever got merged. :-( At this point, since it got so old, can you add Cc to stable to the patch before merge? Thanks. The following changes since commit f92c97c8bd77992ff8bd6ef29a23dc82dca799cb: [media] update CARDLIST.em28xx (2012-03-19 23:12:02 -0300) are available in the git repository at: git://git.linuxtv.org/mkrufky/hauppauge.git windham-ids Michael Krufky (1): smsusb: add autodetection support for USB ID 2040:c0a0 drivers/media/dvb/siano/smsusb.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Cheers, Mike -- 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: logitech quickcam 9000 uvcdynctrl broken since kernel 3.2 - PING
Hi Paulo, On Wed 120502, Paulo Assis wrote: > OK, so UVCIOC_CTRL_ADD is no longer available, now we have: > > UVCIOC_CTRL_MAP and UVCIOC_CTRL_QUERY, so I guess some changes are > needed, I'll try to fix this ASAP. compiled libwebcam-0.2.1 from Ubuntu (had to fight against CMake - I am almost CMake agnostic so far...) and I got the manual focus control in guvcview so things are definitely looking better now. So far I have got a focus slider and a LED1 frequency slider, but not a LED mode... forgot what exactly was available in the past. --- LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/uvcdynctrl -i /usr/share/uvcdynctrl/data/046d/logitech.xml [libwebcam] Unsupported V4L2_CID_EXPOSURE_AUTO control with a non-contiguous range of choice IDs found [libwebcam] Invalid or unsupported V4L2 control encountered: ctrl_id = 0x009A0901, name = 'Exposure, Auto' Importing dynamic controls from file /usr/share/uvcdynctrl/data/046d/logitech.xml. /usr/share/uvcdynctrl/data/046d/logitech.xml: error: video0: unable to map 'Pan (relative)' control. ioctl(UVCIOC_CTRL_MAP) failed with return value -1 (error 2: No such file or directory) /usr/share/uvcdynctrl/data/046d/logitech.xml: error: video0: unable to map 'Tilt (relative)' control. ioctl(UVCIOC_CTRL_MAP) failed with return value -1 (error 2: No such file or directory) /usr/share/uvcdynctrl/data/046d/logitech.xml:354: error: Invalid V4L2 control type specified: 'V4L2_CTRL_TYPE_BUTTON' /usr/share/uvcdynctrl/data/046d/logitech.xml:368: error: Invalid V4L2 control type specified: 'V4L2_CTRL_TYPE_BUTTON' /usr/share/uvcdynctrl/data/046d/logitech.xml:396: error: Invalid V4L2 control type specified: 'V4L2_CTRL_TYPE_MENU' Thanks again, Karl > > Regards, > Paulo -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 1/2] v4l: Do not use enums in IOCTL structs
Answering myself. On Thu, 03 May 2012 12:57:00 +0200, Rémi Denis-Courmont wrote: > On Thu, 3 May 2012 00:39:15 +0300, Sakari Ailus > wrote: >> - ppc64: int is 64 bits there, and thus also enums, > > Really? No, really not: http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUND-TYPE -- Rémi Denis-Courmont Sent from my collocated server -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 1/2] v4l: Do not use enums in IOCTL structs
On Thu, 3 May 2012 00:39:15 +0300, Sakari Ailus wrote: > - ppc64: int is 64 bits there, and thus also enums, Really? (e)glibc assumes that signed int and unsigned int are 32-bits on all platforms. From bits/types.h: typedef signed int __int32_t; typedef unsigned int __uint32_t; > - C does not specify which integer type enums actually use; this is what > GCC manual says about it: The Linux ABI, at least as defined in GCC, requires 'short enums' be disabled, even on ARM. So enums should always be unsigned or int with gcc, thus with V4L2 code. -- Rémi Denis-Courmont -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] Convert I2C drivers to dev_pm_ops
The legacy I2C PM functions have been deprecated and warning on boot
for over a year, convert the drivers still using them to dev_pm_ops.
Signed-off-by: Mark Brown
---
drivers/media/video/msp3400-driver.c | 15 +++
drivers/media/video/tuner-core.c | 15 +++
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/msp3400-driver.c
b/drivers/media/video/msp3400-driver.c
index 82ce507..aeb22be 100644
--- a/drivers/media/video/msp3400-driver.c
+++ b/drivers/media/video/msp3400-driver.c
@@ -597,19 +597,23 @@ static int msp_log_status(struct v4l2_subdev *sd)
return 0;
}
-static int msp_suspend(struct i2c_client *client, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int msp_suspend(struct device *dev)
{
+ struct i2c_client *client = to_i2c_client(dev);
v4l_dbg(1, msp_debug, client, "suspend\n");
msp_reset(client);
return 0;
}
-static int msp_resume(struct i2c_client *client)
+static int msp_resume(struct device *dev)
{
+ struct i2c_client *client = to_i2c_client(dev);
v4l_dbg(1, msp_debug, client, "resume\n");
msp_wake_thread(client);
return 0;
}
+#endif
/* --- */
@@ -863,6 +867,10 @@ static int msp_remove(struct i2c_client *client)
/* --- */
+static const struct dev_pm_ops msp3400_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(msp_suspend, msp_resume)
+};
+
static const struct i2c_device_id msp_id[] = {
{ "msp3400", 0 },
{ }
@@ -873,11 +881,10 @@ static struct i2c_driver msp_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "msp3400",
+ .pm = &msp3400_pm_ops,
},
.probe = msp_probe,
.remove = msp_remove,
- .suspend= msp_suspend,
- .resume = msp_resume,
.id_table = msp_id,
};
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index a5c6397..3e050e1 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -1241,8 +1241,10 @@ static int tuner_log_status(struct v4l2_subdev *sd)
return 0;
}
-static int tuner_suspend(struct i2c_client *c, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int tuner_suspend(struct device *dev)
{
+ struct i2c_client *c = to_i2c_client(dev);
struct tuner *t = to_tuner(i2c_get_clientdata(c));
struct analog_demod_ops *analog_ops = &t->fe.ops.analog_ops;
@@ -1254,8 +1256,9 @@ static int tuner_suspend(struct i2c_client *c,
pm_message_t state)
return 0;
}
-static int tuner_resume(struct i2c_client *c)
+static int tuner_resume(struct device *dev)
{
+ struct i2c_client *c = to_i2c_client(dev);
struct tuner *t = to_tuner(i2c_get_clientdata(c));
tuner_dbg("resume\n");
@@ -1266,6 +1269,7 @@ static int tuner_resume(struct i2c_client *c)
return 0;
}
+#endif
static int tuner_command(struct i2c_client *client, unsigned cmd, void *arg)
{
@@ -1310,6 +1314,10 @@ static const struct v4l2_subdev_ops tuner_ops = {
* I2C structs and module init functions
*/
+static const struct dev_pm_ops tuner_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(tuner_suspend, tuner_resume)
+};
+
static const struct i2c_device_id tuner_id[] = {
{ "tuner", }, /* autodetect */
{ }
@@ -1320,12 +1328,11 @@ static struct i2c_driver tuner_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "tuner",
+ .pm = &tuner_pm_ops,
},
.probe = tuner_probe,
.remove = tuner_remove,
.command= tuner_command,
- .suspend= tuner_suspend,
- .resume = tuner_resume,
.id_table = tuner_id,
};
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 1/2] v4l: Do not use enums in IOCTL structs
On 05/03/2012 12:22 PM, Mauro Carvalho Chehab wrote:
Em 02-05-2012 21:42, Andy Walls escreveu:
On Wed, 2012-05-02 at 19:17 -0300, Mauro Carvalho Chehab wrote:
We can speed-up the conversions, with something like:
enum foo {
BAR
};
if (sizeof(foo) != sizeof(u32))
call_compat_logic().
I suspect that sizeof() won't work inside a macro.
sizeof() is evaluated at compile time, after preprocessing.
It should work inside of a macro.
I tried to compile this small piece of code:
enum foo { BAR };
#if sizeof(foo) != sizeof(int)
void main(void) { printf("different sizes\n"); }
#else
void main(void) { printf("same size\n"); }
#endif
It gives an error:
/tmp/foo.c:2:11: error: missing binary operator before token "("
So, either this doesn't work, because sizeof() is evaluated too late,
or some trick is needed.
The GCC C preprocessor documentation [1] states it won't work that way:
"The preprocessor does not know anything about types in the language.
Therefore, sizeof operators are not recognized in `#if', and neither are
enum constants. They will be taken as identifiers which are not macros,
and replaced by zero. In the case of sizeof, this is likely to cause the
expression to be invalid."
[1] http://gcc.gnu.org/onlinedocs/cpp/If.html#If
Regards,
Sylwester
Weird enough, cpp generates the error, but the expression is well-evaluated:
$ cpp /tmp/foo.c
# 1 "/tmp/foo.c"
# 1 ""
# 1 ""
# 1 "/tmp/foo.c"
/tmp/foo.c:2:11: error: missing binary operator before token "("
enum foo { BAR };
void main(void) { printf("same size\n"); }
Changing from "sizeof(foo)" to "sizeof foo" also doesn't solve:
/tmp/foo.c:2:12: error: missing binary operator before token "foo"
Maybe some trick is needed for it to work.
See the ARRAY_SIZE() macro in include/linux/kernel.h for a well tested
example.
ARRAY_SIZE() doesn't have an #if on it.
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 1/2] v4l: Do not use enums in IOCTL structs
Em 02-05-2012 21:42, Andy Walls escreveu:
> On Wed, 2012-05-02 at 19:17 -0300, Mauro Carvalho Chehab wrote:
>
>> We can speed-up the conversions, with something like:
>>
>> enum foo {
>> BAR
>> };
>>
>> if (sizeof(foo) != sizeof(u32))
>> call_compat_logic().
>>
>> I suspect that sizeof() won't work inside a macro.
>
> sizeof() is evaluated at compile time, after preprocessing.
> It should work inside of a macro.
According with Dennis Ritchie, testing for sizeof on a macro never worked:
http://groups.google.com/group/comp.std.c/msg/4852afc61a060d89?dmode=source&pli=1
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 1/2] v4l: Do not use enums in IOCTL structs
Hi Mauro,
Mauro Carvalho Chehab wrote:
Em 02-05-2012 21:42, Andy Walls escreveu:
On Wed, 2012-05-02 at 19:17 -0300, Mauro Carvalho Chehab wrote:
We can speed-up the conversions, with something like:
enum foo {
BAR
};
if (sizeof(foo) != sizeof(u32))
call_compat_logic().
I suspect that sizeof() won't work inside a macro.
sizeof() is evaluated at compile time, after preprocessing.
It should work inside of a macro.
I tried to compile this small piece of code:
enum foo { BAR };
#if sizeof(foo) != sizeof(int)
void main(void) { printf("different sizes\n"); }
#else
void main(void) { printf("same size\n"); }
#endif
It gives an error:
/tmp/foo.c:2:11: error: missing binary operator before token "("
So, either this doesn't work, because sizeof() is evaluated too late,
or some trick is needed.
Weird enough, cpp generates the error, but the expression is well-evaluated:
$ cpp /tmp/foo.c
# 1 "/tmp/foo.c"
# 1 ""
# 1 ""
# 1 "/tmp/foo.c"
/tmp/foo.c:2:11: error: missing binary operator before token "("
enum foo { BAR };
sizeof() is processed by C compiler while #if is preprocessor directive,
and its arguments have to be evaluable by the preprocessor, which is the
problem here.
The C compiler can also optimise away things like that but it's more
difficult to see whether that takes place or not; one would need to look
at the resulting assembly code.
Regards,
--
Sakari Ailus
sakari.ai...@iki.fi
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 1/2] v4l: Do not use enums in IOCTL structs
Em 02-05-2012 21:42, Andy Walls escreveu:
> On Wed, 2012-05-02 at 19:17 -0300, Mauro Carvalho Chehab wrote:
>
>> We can speed-up the conversions, with something like:
>>
>> enum foo {
>> BAR
>> };
>>
>> if (sizeof(foo) != sizeof(u32))
>> call_compat_logic().
>>
>> I suspect that sizeof() won't work inside a macro.
>
> sizeof() is evaluated at compile time, after preprocessing.
> It should work inside of a macro.
I tried to compile this small piece of code:
enum foo { BAR };
#if sizeof(foo) != sizeof(int)
void main(void) { printf("different sizes\n"); }
#else
void main(void) { printf("same size\n"); }
#endif
It gives an error:
/tmp/foo.c:2:11: error: missing binary operator before token "("
So, either this doesn't work, because sizeof() is evaluated too late,
or some trick is needed.
Weird enough, cpp generates the error, but the expression is well-evaluated:
$ cpp /tmp/foo.c
# 1 "/tmp/foo.c"
# 1 ""
# 1 ""
# 1 "/tmp/foo.c"
/tmp/foo.c:2:11: error: missing binary operator before token "("
enum foo { BAR };
void main(void) { printf("same size\n"); }
Changing from "sizeof(foo)" to "sizeof foo" also doesn't solve:
/tmp/foo.c:2:12: error: missing binary operator before token "foo"
Maybe some trick is needed for it to work.
> See the ARRAY_SIZE() macro in include/linux/kernel.h for a well tested
> example.
ARRAY_SIZE() doesn't have an #if on it.
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
R: Problem with Creative Technology, Ltd Live! Cam Optia AF
Hi I've installed kubuntu 12.04 on my desktop (from kubuntu 10.04) and now the webcam doesn't work, below the are some command lsusb Bus 001 Device 002: ID 041e:4058 Creative Technology, Ltd Live! Cam Optia AF Bus 002 Device 003: ID 07ca:850a AVerMedia Technologies, Inc. AverTV Volar Black HD (A850) Bus 005 Device 002: ID 045e:0734 Microsoft Corp. Wireless Optical Desktop 700 ~$ dmesg | grep usb [0.575334] usbcore: registered new interface driver usbfs [0.575334] usbcore: registered new interface driver hub [0.575334] usbcore: registered new device driver usb [2.164030] usb 1-4: new high speed USB device number 2 using ehci_hcd [2.728040] usb 2-3: new high speed USB device number 3 using ehci_hcd [3.128067] usb 5-1: new low speed USB device number 2 using ohci_hcd [3.318195] input: Liteon Microsoft® Wireless Receiver 700 v2.0 as /devices/pci:00/:00:13.0/usb5/5-1/5-1:1.0/input/input2 [3.318255] generic-usb 0003:045E:0734.0001: input,hidraw0: USB HID v1.11 Keyboard [Liteon Microsoft® Wireless Receiver 700 v2.0] on usb-:00:13.0-1/input0 [3.332228] input: Liteon Microsoft® Wireless Receiver 700 v2.0 as /devices/pci:00/:00:13.0/usb5/5-1/5-1:1.1/input/input3 [3.332297] generic-usb 0003:045E:0734.0002: input,hidraw1: USB HID v1.11 Mouse [Liteon Microsoft® Wireless Receiver 700 v2.0] on usb-:00:13.0-1/input1 [3.332309] usbcore: registered new interface driver usbhid [3.332310] usbhid: USB HID core driver [ 15.113133] usbcore: registered new interface driver snd-usb-audio [ 15.120717] input: UVC Camera (041e:4058) as /devices/pci:00/:00:12.2/usb1/1-4/1-4:1.0/input/input6 [ 15.120816] usbcore: registered new interface driver uvcvideo [ 15.488022] dvb-usb: found a 'AverMedia AVerTV Volar Black HD (A850)' in cold state, will try to load a firmware [ 15.530772] dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw' [ 15.598250] dvb-usb: found a 'AverMedia AVerTV Volar Black HD (A850)' in warm state. [ 15.598289] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 15.606392] dvb-usb: AverMedia AVerTV Volar Black HD (A850) successfully initialized and connected. [ 15.612650] usbcore: registered new interface driver dvb_usb_af9015 $ dmesg | grep UVC [ 15.117016] uvcvideo: Found UVC 1.00 device (041e:4058) [ 15.120717] input: UVC Camera (041e:4058) as /devices/pci:00/:00:12.2/usb1/1-4/1-4:1.0/input/input6 $ lsmod | grep uvcvideo uvcvideo 72711 0 videodev 93004 1 uvcvideo $ ls -l /dev/video* crw-rw+ 1 root video 81, 0 2011-11-02 19:28 /dev/video0 the webcam doesn't work with any software, in the google search I found the same problem on fedora on link https://bugzilla.redhat.com/show_bug.cgi?id=739448 If I downgrade the kernel to 2.6.38.12 the webcam work fine !! I think that the problem is on the UVC driver on the kernel after 2.6.38.12 to latest kernel Thanks Tiziano -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] add support for DeLOCK-USB-2.0-DVB-T-Receiver-61744
Hi poma, I have a 0BDA:2838 (Easycap EZTV646) and a 0BDA:2832 (no name 20x20mm mini DVB-T stick) and both are based on the E4000 tuner, which is not supported in the kernel at the moment. I have no idea if there are sticks with the same USB PID and the fc0012 tuner. Regards, Gianluca Il 03/05/2012 09:25, poma ha scritto: > > [ …] > > Hi there, > > These two patches - 'dvb-usb-ids-v2-rtl2832-fc0012.patch' and > 'rtl28xxu-v2-rtl2832-fc0012.patch' adds nine devices based on FC0012 > tuner, altogether eleven. > Gianluca, please inform forum fellows to test&reply. > Zdenek, fermio - there is a note on > http://wiki.zeratul.org/doku.php?id=linux:v4l:realtek:start at > "Other DVB-T Sticks" regarding 'af4d:a803' device. > Is it based on RTL2832 with FC0012 tuner? > > Julian, Thomas, Antii > cheers mates! > ;) > poma > > ps. > modinfo dvb_usb_rtl28xxu > filename: > /lib/modules/3.3.2-6.fc16.x86_64/kernel/drivers/media/dvb/dvb-usb/dvb-usb-rtl28xxu.ko > license:GPL > author: Thomas Mair > author: Antti Palosaari > description:Realtek RTL28xxU DVB USB driver > alias: usb:v1F4DpD803d*dc*dsc*dp*ic*isc*ip* > alias: usb:v1F4DpC803d*dc*dsc*dp*ic*isc*ip* > alias: usb:v1B80pD399d*dc*dsc*dp*ic*isc*ip* > alias: usb:v1B80pD395d*dc*dsc*dp*ic*isc*ip* > alias: usb:v1B80pD394d*dc*dsc*dp*ic*isc*ip* > alias: usb:v1B80pD393d*dc*dsc*dp*ic*isc*ip* > alias: usb:v1B80pD39Dd*dc*dsc*dp*ic*isc*ip* > alias: usb:v0458p707Fd*dc*dsc*dp*ic*isc*ip* > alias: usb:v0BDAp2838d*dc*dsc*dp*ic*isc*ip* > alias: usb:v1F4DpB803d*dc*dsc*dp*ic*isc*ip* > alias: usb:v0CCDp00A9d*dc*dsc*dp*ic*isc*ip* > alias: usb:v14AAp0161d*dc*dsc*dp*ic*isc*ip* > alias: usb:v14AAp0160d*dc*dsc*dp*ic*isc*ip* > alias: usb:v0BDAp2831d*dc*dsc*dp*ic*isc*ip* > depends:dvb-usb,rtl2830,rc-core > vermagic: 3.3.2-6.fc16.x86_64 SMP mod_unload > parm: debug:set debugging level (int) > parm: adapter_nr:DVB adapter numbers (array of short) > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] add support for DeLOCK-USB-2.0-DVB-T-Receiver-61744
[
…]
Hi there,
These two patches - 'dvb-usb-ids-v2-rtl2832-fc0012.patch' and
'rtl28xxu-v2-rtl2832-fc0012.patch' adds nine devices based on FC0012
tuner, altogether eleven.
Gianluca, please inform forum fellows to test&reply.
Zdenek, fermio - there is a note on
http://wiki.zeratul.org/doku.php?id=linux:v4l:realtek:start at
"Other DVB-T Sticks" regarding 'af4d:a803' device.
Is it based on RTL2832 with FC0012 tuner?
Julian, Thomas, Antii
cheers mates!
;)
poma
ps.
modinfo dvb_usb_rtl28xxu
filename:
/lib/modules/3.3.2-6.fc16.x86_64/kernel/drivers/media/dvb/dvb-usb/dvb-usb-rtl28xxu.ko
license:GPL
author: Thomas Mair
author: Antti Palosaari
description:Realtek RTL28xxU DVB USB driver
alias: usb:v1F4DpD803d*dc*dsc*dp*ic*isc*ip*
alias: usb:v1F4DpC803d*dc*dsc*dp*ic*isc*ip*
alias: usb:v1B80pD399d*dc*dsc*dp*ic*isc*ip*
alias: usb:v1B80pD395d*dc*dsc*dp*ic*isc*ip*
alias: usb:v1B80pD394d*dc*dsc*dp*ic*isc*ip*
alias: usb:v1B80pD393d*dc*dsc*dp*ic*isc*ip*
alias: usb:v1B80pD39Dd*dc*dsc*dp*ic*isc*ip*
alias: usb:v0458p707Fd*dc*dsc*dp*ic*isc*ip*
alias: usb:v0BDAp2838d*dc*dsc*dp*ic*isc*ip*
alias: usb:v1F4DpB803d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0CCDp00A9d*dc*dsc*dp*ic*isc*ip*
alias: usb:v14AAp0161d*dc*dsc*dp*ic*isc*ip*
alias: usb:v14AAp0160d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0BDAp2831d*dc*dsc*dp*ic*isc*ip*
depends:dvb-usb,rtl2830,rc-core
vermagic: 3.3.2-6.fc16.x86_64 SMP mod_unload
parm: debug:set debugging level (int)
parm: adapter_nr:DVB adapter numbers (array of short)
--- dvb-usb-ids.h.bcp 2012-05-03 05:28:38.261673063 +0200
+++ dvb-usb-ids.h 2012-05-03 07:07:41.510306992 +0200
@@ -129,10 +129,12 @@
#define USB_PID_E3C_EC168_30xfffb
#define USB_PID_E3C_EC168_40x1001
#define USB_PID_E3C_EC168_50x1002
+#define USB_PID_EZCAP_EZTV6460x2838
#define USB_PID_FREECOM_DVBT0x0160
#define USB_PID_FREECOM_DVBT_20x0161
#define USB_PID_UNIWILL_STK7700P 0x6003
#define USB_PID_GENIUS_TVGO_DVB_T03 0x4012
+#define USB_PID_GENIUS_TVGO_DVB_T03_2 0x707f
#define USB_PID_GRANDTEC_DVBT_USB_COLD 0x0fa0
#define USB_PID_GRANDTEC_DVBT_USB_WARM 0x0fa1
#define USB_PID_GTEK 0xb803
@@ -146,6 +148,9 @@
#define USB_PID_KWORLD_395U_20xe39b
#define USB_PID_KWORLD_395U_30xe395
#define USB_PID_KWORLD_395U_40xe39a
+#define USB_PID_KWORLD_D3930xd393
+#define USB_PID_KWORLD_D3950xd395
+#define USB_PID_KWORLD_D3990xd399
#define USB_PID_KWORLD_MC8100xc810
#define USB_PID_KWORLD_PC160_2T0xc160
#define USB_PID_KWORLD_PC160_T0xc161
@@ -209,6 +214,7 @@
#define USB_PID_HAUPPAUGE_NOVA_TD_STICK_52009 0x5200
#define USB_PID_HAUPPAUGE_TIGER_ATSC 0xb200
#define USB_PID_HAUPPAUGE_TIGER_ATSC_B210 0xb210
+#define USB_PID_HU394 0xd394
#define USB_PID_AVERMEDIA_EXPRESS 0xb568
#define USB_PID_AVERMEDIA_VOLAR0xa807
#define USB_PID_AVERMEDIA_VOLAR_2 0xb808
@@ -265,11 +271,13 @@
#define USB_PID_PCTV_400E0x020f
#define USB_PID_PCTV_450E0x0222
#define USB_PID_PCTV_452E0x021f
+#define USB_PID_PROLECTRIX_DV107669 0xd803
#define USB_PID_REALTEK_RTL2831U 0x2831
#define USB_PID_REALTEK_RTL2832U 0x2832
#define USB_PID_TECHNOTREND_CONNECT_S2_3600 0x3007
#define USB_PID_TECHNOTREND_CONNECT_S2_3650_CI 0x300a
#define USB_PID_NEBULA_DIGITV0x0201
+#define USB_PID_NOT_ONLY_LV5TDELUXE 0xc803
#define USB_PID_DVICO_BLUEBIRD_LGDT 0xd820
#define USB_PID_DVICO_BLUEBIRD_LG064F_COLD 0xd500
#define USB_PID_DVICO_BLUEBIRD_LG064F_WARM 0xd501
@@ -345,6 +353,7 @@
#define USB_PID_FRIIO_WHITE0x0001
#define USB_PID_TVWAY_PLUS0x0002
#define USB_PID_SVEON_STV200xe39d
+#define USB_PID_SVEON_STV20_20xd39d
#define USB_PID_SVEON_STV220xe401
#define USB_PID_SVEON_STV22_IT9137 0xe411
#define USB_PID_AZUREWAVE_AZ6027 0x3275
--- rtl28xxu.c.bcp 2012-05-03 06:44:32.958461395 +0200
+++ rtl28xxu.c 2012-05-03 08:11:57.463559065 +0200
@@ -1052,6 +1052,15 @@
RTL2831U_14AA_0161,
RTL2832U_0CCD_00A9,
RTL2832U_1F4D_B803,
+ RTL2832U_0BDA_2838,
+ RTL2832U_0458_707F,
+ RTL2832U_1B80_D39D,
+ RTL2832U_1B80_D393,
+ RTL2832U_1B80_D394,
+ RTL2832U_1B80_D395,
+ RTL2832U_1B80_D399,
+ RTL2832U_1F4D_C803,
+ RTL2832U_1F4D_D803,
};
static struct usb_device_id rtl28xxu_table[] = {
@@ -1068,6 +1077,24 @@
USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_CINERGY_T_STICK_BLACK)},
[RTL2832U_1F4D_B803] = {
USB_DEVICE(USB_VID_GTEK, USB_PID_GTEK)},
+ [RTL2832U_0BDA_2838] = {
+ USB_DEVICE(USB_VID_REALTEK, USB_PID_EZCAP_EZTV646)},
+ [RTL2832U_0458_707F] = {
+ USB_DEVICE(USB_VID_KYE, USB_PID_GENIUS_TVGO_DVB_T03_2)},
+ [RTL2832U_1B80_D39D] = {
+ USB_DEVICE(USB_VID_KWORLD_2, USB_PID_SVEON_STV20_2)},
+ [RTL2832U_1B80_D393] = {
+ USB_DEVICE(USB_VID_KWORLD_2, USB_PID_KWORLD_D393)},
+ [RTL2832U_1B80_D394] = {
+ USB_DEVICE(USB_VID_KWORLD_2, USB_PID_HU394)},
+ [RTL2832U_1B80_D395]
Re: [PATCH V3 4/5] [Documentation] Media: Update docs for V4L2 FM new features
On Wed May 2 2012 23:42:30 manjunatha_ha...@ti.com wrote:
> From: Manjunatha Halli
>
> The list of new features -
> 1) New control class for FM RX
> 2) New FM RX CID's - De-Emphasis filter mode and RDS AF switch
> 3) New FM TX CID - RDS Alternate frequency set.
>
> Signed-off-by: Manjunatha Halli
> ---
> Documentation/DocBook/media/v4l/compat.xml |3 +
> Documentation/DocBook/media/v4l/controls.xml | 78
>
> Documentation/DocBook/media/v4l/dev-rds.xml|5 +-
> .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |7 ++
> .../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml|7 ++-
> 5 files changed, 97 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/DocBook/media/v4l/compat.xml
> b/Documentation/DocBook/media/v4l/compat.xml
> index bce97c5..df1f345 100644
> --- a/Documentation/DocBook/media/v4l/compat.xml
> +++ b/Documentation/DocBook/media/v4l/compat.xml
> @@ -2311,6 +2311,9 @@ more information.
> Added FM Modulator (FM TX) Extended Control Class:
> V4L2_CTRL_CLASS_FM_TX and their Control IDs.
>
>
> + Added FM Receiver (FM RX) Extended Control Class:
> V4L2_CTRL_CLASS_FM_RX and their Control IDs.
> +
> +
> Added Remote Controller chapter, describing the default Remote
> Controller mapping for media devices.
>
>
> diff --git a/Documentation/DocBook/media/v4l/controls.xml
> b/Documentation/DocBook/media/v4l/controls.xml
> index b84f25e..b6e4db2 100644
> --- a/Documentation/DocBook/media/v4l/controls.xml
> +++ b/Documentation/DocBook/media/v4l/controls.xml
> @@ -3018,6 +3018,12 @@ to find receivers which can scroll strings sized as 32
> x N or 64 x N characters.
> with steps of 32 or 64 characters. The result is it must always contain a
> string with size multiple of 32 or 64.
>
>
> +spanname="id">V4L2_CID_RDS_TX_AF_FREQ
> + integer
> +
> + Sets the RDS Alternate Frequency value
> which allows a receiver to re-tune to a different frequency providing the
> same station when the first signal becomes too weak (e.g., when moving out of
> range).
> +
> +
>spanname="id">V4L2_CID_AUDIO_LIMITER_ENABLED
> boolean
>
> @@ -3146,6 +3152,78 @@ manually or automatically if set to zero. Unit, range
> and step are driver-specif
> document, from CENELEC.
>
>
> +
> + FM Receiver Control Reference
> +
> + The FM Receiver (FM_RX) class includes controls for common
> features of
> +FM Reception capable devices. Currently this class includes parameter for
> Alternate
> +frequency.
Remove the last sentence ("Currently this..."). It serves no purpose and would
only need
to be updated whenever a control is added.
> +
> +
> + FM_RX Control IDs
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +ID
> +Type
> + align="left">Description
> +
> +
> +
> +
> +
> + spanname="id">V4L2_CID_FM_RX_CLASS
> +class
> + The FM_RX class
> +descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a
> +description of this control class.
> +
> +
> + spanname="id">V4L2_CID_RDS_AF_SWITCH
> +boolean
> +
> + Enable/Disable's FM RX RDS Alternate
> frequency feature. When enabled driver will decode the RDS AF field and tries
> to switch to this AF frequency once current frequency RSSI level goes below
> threshold. Value of G_FREQUENCY is unchanged since both original frequency
> and AF frequency share the same PI code.
Small improvement: Enable/Disable's -> Enable or Disable the
I'd also remove the "FM RX" part: it's already obvious that we are in the FM RX
class of controls.
"When enabled" -> "When enabled the"
"once current" -> once the current"
"below threshold" -> "below the threshold"
I don't understand what you mean with the last sentence: "Value of
G_FREQUENCY...".
Shouldn't it be something like:
If the frequency is switched, then &VIDIOC-G-FREQUENCY; will return the new
frequency."
> +
> +
> + spanname="id">V4L2_CID_TUNE_DEEMPHASIS
> + integer
> +
> + Configures the
> de-emphasis value for reception.
> +A pre-emphasis filter is applied to the broadcast to accentuate the high
> audio frequencies.
> +Depending on the region, a time constant of either 50 or 75 useconds is
> used. The enum v4l2_preemphasis
> +defines possible values for pre-emphasis. Here they are:
> +
> +
> +
> +
> +
> V4L2_PREEMPHASIS_DISABLED
> + No de-emphasis is applied.
> +
> +
> +
> V4L2_PREEMPHASIS_50_uS
> + A de-emphasis of
Re: [PATCH V3 2/5] [Media] New control class and features for FM RX
On Thu May 3 2012 09:08:57 Hans Verkuil wrote:
> Just a few more minor notes:
>
> On Wed May 2 2012 23:42:28 manjunatha_ha...@ti.com wrote:
> > From: Manjunatha Halli
> >
> > This patch creates new ctrl class for FM RX and adds new CID's for
> > below FM features,
> > 1) De-Emphasis filter mode
> > 2) RDS AF switch
> >
> > Also this patch adds a field for band selection in struct v4l2_hw_freq_seek
> >
> > Signed-off-by: Manjunatha Halli
> > ---
> > drivers/media/video/v4l2-ctrls.c | 17 +
> > include/linux/videodev2.h| 11 ++-
> > 2 files changed, 27 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/media/video/v4l2-ctrls.c
> > b/drivers/media/video/v4l2-ctrls.c
> > index 18015c0..e1bba7d 100644
> > --- a/drivers/media/video/v4l2-ctrls.c
> > +++ b/drivers/media/video/v4l2-ctrls.c
> > @@ -372,6 +372,12 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> > NULL,
> > };
> >
> > + static const char * const tune_deemphasis[] = {
> > + "No deemphasis",
> > + "50 useconds",
> > + "75 useconds",
> > + NULL,
> > + };
>
> I suggest that we re-use tune_preemphasis[] here. Just replace the first
> entry from "No Preemphasis" to "None" to make it generic.
>
> Rename tune_preemphasis[] to tune_emphasis[] as well.
>
> > switch (id) {
> > case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
> > return mpeg_audio_sampling_freq;
> > @@ -414,6 +420,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> > return colorfx;
> > case V4L2_CID_TUNE_PREEMPHASIS:
> > return tune_preemphasis;
> > + case V4L2_CID_TUNE_DEEMPHASIS:
> > + return tune_deemphasis;
> > case V4L2_CID_FLASH_LED_MODE:
> > return flash_led_mode;
> > case V4L2_CID_FLASH_STROBE_SOURCE:
> > @@ -644,6 +652,12 @@ const char *v4l2_ctrl_get_name(u32 id)
> > case V4L2_CID_JPEG_COMPRESSION_QUALITY: return "Compression Quality";
> > case V4L2_CID_JPEG_ACTIVE_MARKER: return "Active Markers";
> >
> > + /* FM Radio Receiver control */
> > + /* Keep the order of the 'case's the same as in videodev2.h! */
> > + case V4L2_CID_FM_RX_CLASS: return "FM Radio Receiver
> > Controls";
> > + case V4L2_CID_RDS_AF_SWITCH:return "FM RX RDS AF switch";
>
> I would call this "RDS AF Switch" or perhaps even better: "RDS Auto-Frequency
> Switch"
Sorry, that should have been: "RDS Alternate Frequency Switch".
Regards,
Hans
>
> > + case V4L2_CID_TUNE_DEEMPHASIS: return "FM RX De-emphasis
> > settings";
>
> Rename to "De-Emphasis" to be consistent with the existing "Pre-Emphasis"
> string.
>
> 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 V3 2/5] [Media] New control class and features for FM RX
Just a few more minor notes:
On Wed May 2 2012 23:42:28 manjunatha_ha...@ti.com wrote:
> From: Manjunatha Halli
>
> This patch creates new ctrl class for FM RX and adds new CID's for
> below FM features,
> 1) De-Emphasis filter mode
> 2) RDS AF switch
>
> Also this patch adds a field for band selection in struct v4l2_hw_freq_seek
>
> Signed-off-by: Manjunatha Halli
> ---
> drivers/media/video/v4l2-ctrls.c | 17 +
> include/linux/videodev2.h| 11 ++-
> 2 files changed, 27 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/video/v4l2-ctrls.c
> b/drivers/media/video/v4l2-ctrls.c
> index 18015c0..e1bba7d 100644
> --- a/drivers/media/video/v4l2-ctrls.c
> +++ b/drivers/media/video/v4l2-ctrls.c
> @@ -372,6 +372,12 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> NULL,
> };
>
> + static const char * const tune_deemphasis[] = {
> + "No deemphasis",
> + "50 useconds",
> + "75 useconds",
> + NULL,
> + };
I suggest that we re-use tune_preemphasis[] here. Just replace the first
entry from "No Preemphasis" to "None" to make it generic.
Rename tune_preemphasis[] to tune_emphasis[] as well.
> switch (id) {
> case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
> return mpeg_audio_sampling_freq;
> @@ -414,6 +420,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> return colorfx;
> case V4L2_CID_TUNE_PREEMPHASIS:
> return tune_preemphasis;
> + case V4L2_CID_TUNE_DEEMPHASIS:
> + return tune_deemphasis;
> case V4L2_CID_FLASH_LED_MODE:
> return flash_led_mode;
> case V4L2_CID_FLASH_STROBE_SOURCE:
> @@ -644,6 +652,12 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_JPEG_COMPRESSION_QUALITY: return "Compression Quality";
> case V4L2_CID_JPEG_ACTIVE_MARKER: return "Active Markers";
>
> + /* FM Radio Receiver control */
> + /* Keep the order of the 'case's the same as in videodev2.h! */
> + case V4L2_CID_FM_RX_CLASS: return "FM Radio Receiver
> Controls";
> + case V4L2_CID_RDS_AF_SWITCH:return "FM RX RDS AF switch";
I would call this "RDS AF Switch" or perhaps even better: "RDS Auto-Frequency
Switch"
> + case V4L2_CID_TUNE_DEEMPHASIS: return "FM RX De-emphasis
> settings";
Rename to "De-Emphasis" to be consistent with the existing "Pre-Emphasis"
string.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 1/2] v4l: Do not use enums in IOCTL structs
On Wed May 2 2012 23:39:15 Sakari Ailus wrote: > Hi Hans, > > On Wed, May 02, 2012 at 10:45:22PM +0200, Hans Verkuil wrote: > > On Wed May 2 2012 21:13:47 Sakari Ailus wrote: > > > Replace enums in IOCTL structs by __u32. The size of enums is variable and > > > thus problematic. Compatibility structs having exactly the same as > > > original > > > definition are provided for compatibility with old binaries with the > > > required conversion code. > > > > Does someone actually have hard proof that there really is a problem? You > > know, > > demonstrate it with actual example code? > > > > It's pretty horrible that you have to do all those conversions and that code > > will be with us for years to come. > > > > For most (if not all!) architectures sizeof(enum) == sizeof(u32), so there > > is > > no need for any compat code for those. > > Cases I know where this can go wrong are, but there may well be others: > > - ppc64: int is 64 bits there, and thus also enums, Are you really, really certain that's the case? If I look at arch/powerpc/include/asm/types.h it includes either asm-generic/int-l64.h or asm-generic/int-ll64.h and both of those headers define u32 as unsigned int. Also, if sizeof(int) != 4, then how would you define u32? Ask a ppc64 kernel maintainer what sizeof(int) and sizeof(enum) are in the kernel before we start doing lots of work for no reason. Looking at arch/*/include/asm/types.h it seems all architectures define sizeof(int) as 4. What sizeof(long) is will actually differ between architectures, but char, short and int seem to be fixed everywhere. Regards, Hans > > - Enums are quite a different concept in C++ than in C --- the compiler may > make assumpton based on the value range of the enums --- videodev2.h should > be included with extern "C" in that case, though, > > - C does not specify which integer type enums actually use; this is what GCC > manual says about it: > > > http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Enumerations> > > So a compiler other than GCC should use 16-bit enums and conform to C > while breaking V4L2. This might be a theoretical issue, though. > > More discussion took place in this thread: > > http://www.spinics.net/lists/linux-media/msg46167.html> > > Regards, > > -- 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
