Re: [PATCH v2 04/31] v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs
Hi Sylwester, On Sat, Feb 04, 2012 at 11:37:38PM +0100, Sylwester Nawrocki wrote: On 02/04/2012 09:30 PM, Sakari Ailus wrote: +#define V4L2_SUBDEV_SEL_FLAG_SIZE_GE (1 0) +#define V4L2_SUBDEV_SEL_FLAG_SIZE_LE (1 1) +#define V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG (1 2) + +/* active cropping area */ +#define V4L2_SUBDEV_SEL_TGT_CROP_ACTIVE 0 +/* cropping bounds */ +#define V4L2_SUBDEV_SEL_TGT_CROP_BOUNDS 2 You've dropped the DEFAULT targets but the target numbers stayed unchanged. How about using hex numbers ? e.g. #define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTIVE 0x0100 #define V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS 0x0101 Fine for me. Changed for the next revision. I wanted to keep the target numbers the same since we're still using exactly the same as the V4L2. You're right, keeping the numbers same for subdevs and regular video nodes may be important. I'm wondering whether we should use same definitions for subdevs, rather than inventing new ones ? In case we associate the selection targets with controls some target identifiers must not actually be different. Whether the control belongs directly to a video node control handler or is inherited from a sub-device the selection target would have to be same. I'm referring here to an auto focus rectangle selection target base for instance. I guess including videodev2.h from v4l2-subdev.h is not an option, if at all necessary ? I think you're right; there would be advantages of using the same definitions. On the other hand, there may be subtle and not so subtle differences what these rectangles actually mean between the two interfaces. The interface is quite similar to controls but the purpose it is used for is quite different: not many interdependencies are expected with controls whereas selections have many. The reason for this is we're using them to control various kinds of image processing functionality which might not be even similar on V4L2 subdev nodes and V4L2 nodes: the former is a superset of the latter. I'd like to have Laurent's opinion on this. 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 2/2] v4l2: add new pixel formats supported on dm365
Hi Manju, On Fri, Jan 20, 2012 at 06:52:19PM +0530, Manjunath Hadli wrote: add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats to represent Bayer format frames compressed by A-LAW alogorithm, add V4L2_PIX_FMT_UV8 to represent storage of C data (UV interleved) only. The patch is finally here: URL:http://www.spinics.net/lists/linux-media/msg43890.html Cheers, -- 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 11/31] v4l: Document raw bayer 4CC codes
Sakari, Thanks for the patch. On 2/3/12, Sakari Ailus sakari.ai...@iki.fi wrote: Document guidelines how 4CC codes should be named. Only raw bayer is included currently. Other formats should be documented later on. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- Documentation/video4linux/4CCs.txt | 32 1 files changed, 32 insertions(+), 0 deletions(-) create mode 100644 Documentation/video4linux/4CCs.txt diff --git a/Documentation/video4linux/4CCs.txt b/Documentation/video4linux/4CCs.txt new file mode 100644 index 000..bb4a97d --- /dev/null +++ b/Documentation/video4linux/4CCs.txt @@ -0,0 +1,32 @@ +Guidelines for Linux4Linux pixel format 4CCs + + +Guidelines for Video4Linux 4CC codes defined using v4l2_fourcc() are +specified in this document. First of the characters defines the nature of +the pixel format, compression and colour space. The interpretation of the +other three characters depends on the first one. + +Existing 4CCs may not obey these guidelines. + +Formats +=== + +Raw bayer +- + +The following first charcters are used by raw bayer formats: A small spelling mistake 'charcters', just pointing out since its a documentation file :-) Regards, --Prabhakar Lad + + B: raw bayer, uncompressed + b: raw bayer, DPCM compressed + a: A-law compressed + u: u-law compressed + +2nd character: pixel order + B: BGGR + G: GBRG + g: GRBG + R: RGGB + +3rd character: uncompressed bits-per-pixel 0--9, A-- + +4th character: compressed bits-per-pixel 0--9, A-- -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
[RFCv1 PATCH 2/2] radio-maxiradio: use the tea575x framework.
From: Hans Verkuil hans.verk...@cisco.com
This card is based on the tea575x receiver. Use the tea575x-tuner framework
instead of reinventing the wheel.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/radio/Kconfig |2 +-
drivers/media/radio/radio-maxiradio.c | 379 ++---
2 files changed, 65 insertions(+), 316 deletions(-)
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 48747df..6591f8b 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -43,7 +43,7 @@ config USB_DSBR
config RADIO_MAXIRADIO
tristate Guillemot MAXI Radio FM 2000 radio
- depends on VIDEO_V4L2 PCI
+ depends on VIDEO_V4L2 PCI SND
---help---
Choose Y here if you have this radio card. This card may also be
found as Gemtek PCI FM.
diff --git a/drivers/media/radio/radio-maxiradio.c
b/drivers/media/radio/radio-maxiradio.c
index f872a54..740a3d5 100644
--- a/drivers/media/radio/radio-maxiradio.c
+++ b/drivers/media/radio/radio-maxiradio.c
@@ -42,67 +42,37 @@
#include linux/videodev2.h
#include linux/io.h
#include linux/slab.h
+#include sound/tea575x-tuner.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
-
-#define DRIVER_VERSION 0.7.8
-
+#include media/v4l2-fh.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-event.h
MODULE_AUTHOR(Dimitromanolakis Apostolos, ap...@grecian.net);
-MODULE_DESCRIPTION(Radio driver for the Guillemot Maxi Radio FM2000 radio.);
+MODULE_DESCRIPTION(Radio driver for the Guillemot Maxi Radio FM2000.);
MODULE_LICENSE(GPL);
-MODULE_VERSION(DRIVER_VERSION);
+MODULE_VERSION(1.0.0);
static int radio_nr = -1;
-module_param(radio_nr, int, 0);
-
-static int debug;
-
-module_param(debug, int, 0644);
-MODULE_PARM_DESC(debug, activates debug info);
-
-#define dprintk(dev, num, fmt, arg...) \
- v4l2_dbg(num, debug, dev-v4l2_dev, fmt, ## arg)
-
-#ifndef PCI_VENDOR_ID_GUILLEMOT
-#define PCI_VENDOR_ID_GUILLEMOT 0x5046
-#endif
-
-#ifndef PCI_DEVICE_ID_GUILLEMOT
-#define PCI_DEVICE_ID_GUILLEMOT_MAXIRADIO 0x1001
-#endif
-
+module_param(radio_nr, int, 0644);
+MODULE_PARM_DESC(radio_nr, Radio device number);
/* TEA5757 pin mappings */
static const int clk = 1, data = 2, wren = 4, mo_st = 8, power = 16;
-#define FREQ_LO(87 * 16000)
-#define FREQ_HI(108 * 16000)
-
-#define FREQ_IF 171200 /* 10.7*16000 */
-#define FREQ_STEP 200/* 12.5*16 */
-
-/* (x==fmhz*16*1000) - bits */
-#define FREQ2BITS(x) \
- unsigned int)(x) + FREQ_IF + (FREQ_STEP 1)) / (FREQ_STEP 2)) 2)
-
-#define BITS2FREQ(x) ((x) * FREQ_STEP - FREQ_IF)
+static atomic_t maxiradio_instance = ATOMIC_INIT(0);
+#define PCI_VENDOR_ID_GUILLEMOT 0x5046
+#define PCI_DEVICE_ID_GUILLEMOT_MAXIRADIO 0x1001
struct maxiradio
{
+ struct snd_tea575x tea;
struct v4l2_device v4l2_dev;
- struct video_device vdev;
struct pci_dev *pdev;
u16 io; /* base of radio io */
- u16 muted; /* VIDEO_AUDIO_MUTE */
- u16 stereo; /* VIDEO_TUNER_STEREO_ON */
- u16 tuned; /* signal strength (0 or 0x) */
-
- unsigned long freq;
-
- struct mutex lock;
};
static inline struct maxiradio *to_maxiradio(struct v4l2_device *v4l2_dev)
@@ -110,259 +80,41 @@ static inline struct maxiradio *to_maxiradio(struct
v4l2_device *v4l2_dev)
return container_of(v4l2_dev, struct maxiradio, v4l2_dev);
}
-static void outbit(unsigned long bit, u16 io)
-{
- int val = power | wren | (bit ? data : 0);
-
- outb(val, io);
- udelay(4);
- outb(val | clk, io);
- udelay(4);
- outb(val, io);
- udelay(4);
-}
-
-static void turn_power(struct maxiradio *dev, int p)
-{
- if (p != 0) {
- dprintk(dev, 1, Radio powered on\n);
- outb(power, dev-io);
- } else {
- dprintk(dev, 1, Radio powered off\n);
- outb(0, dev-io);
- }
-}
-
-static void set_freq(struct maxiradio *dev, u32 freq)
-{
- unsigned long int si;
- int bl;
- int io = dev-io;
- int val = FREQ2BITS(freq);
-
- /* TEA5757 shift register bits (see pdf) */
-
- outbit(0, io); /* 24 search */
- outbit(1, io); /* 23 search up/down */
-
- outbit(0, io); /* 22 stereo/mono */
-
- outbit(0, io); /* 21 band */
- outbit(0, io); /* 20 band (only 00=FM works I think) */
-
- outbit(0, io); /* 19 port ? */
- outbit(0, io); /* 18 port ? */
-
- outbit(0, io); /* 17 search level */
- outbit(0, io); /* 16 search level */
-
- si = 0x8000;
- for (bl = 1; bl = 16; bl++) {
- outbit(val si, io);
- si = 1;
- }
-
- dprintk(dev, 1, Radio freq set to %d.%02d MHz\n,
- freq / 16000,
- freq % 16000 * 100 / 16000);
-
-
Re: [RFCv1 PATCH 2/2] radio-maxiradio: use the tea575x framework.
Please ignore this, I'll repost the proper version soon.
I pressed 'n' when I should have pressed 'q' :-)
On Sunday, February 05, 2012 14:06:32 Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
This card is based on the tea575x receiver. Use the tea575x-tuner framework
instead of reinventing the wheel.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/radio/Kconfig |2 +-
drivers/media/radio/radio-maxiradio.c | 379
++---
2 files changed, 65 insertions(+), 316 deletions(-)
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 48747df..6591f8b 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -43,7 +43,7 @@ config USB_DSBR
config RADIO_MAXIRADIO
tristate Guillemot MAXI Radio FM 2000 radio
- depends on VIDEO_V4L2 PCI
+ depends on VIDEO_V4L2 PCI SND
---help---
Choose Y here if you have this radio card. This card may also be
found as Gemtek PCI FM.
diff --git a/drivers/media/radio/radio-maxiradio.c
b/drivers/media/radio/radio-maxiradio.c
index f872a54..740a3d5 100644
--- a/drivers/media/radio/radio-maxiradio.c
+++ b/drivers/media/radio/radio-maxiradio.c
@@ -42,67 +42,37 @@
#include linux/videodev2.h
#include linux/io.h
#include linux/slab.h
+#include sound/tea575x-tuner.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
-
-#define DRIVER_VERSION 0.7.8
-
+#include media/v4l2-fh.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-event.h
MODULE_AUTHOR(Dimitromanolakis Apostolos, ap...@grecian.net);
-MODULE_DESCRIPTION(Radio driver for the Guillemot Maxi Radio FM2000
radio.);
+MODULE_DESCRIPTION(Radio driver for the Guillemot Maxi Radio FM2000.);
MODULE_LICENSE(GPL);
-MODULE_VERSION(DRIVER_VERSION);
+MODULE_VERSION(1.0.0);
static int radio_nr = -1;
-module_param(radio_nr, int, 0);
-
-static int debug;
-
-module_param(debug, int, 0644);
-MODULE_PARM_DESC(debug, activates debug info);
-
-#define dprintk(dev, num, fmt, arg...) \
- v4l2_dbg(num, debug, dev-v4l2_dev, fmt, ## arg)
-
-#ifndef PCI_VENDOR_ID_GUILLEMOT
-#define PCI_VENDOR_ID_GUILLEMOT 0x5046
-#endif
-
-#ifndef PCI_DEVICE_ID_GUILLEMOT
-#define PCI_DEVICE_ID_GUILLEMOT_MAXIRADIO 0x1001
-#endif
-
+module_param(radio_nr, int, 0644);
+MODULE_PARM_DESC(radio_nr, Radio device number);
/* TEA5757 pin mappings */
static const int clk = 1, data = 2, wren = 4, mo_st = 8, power = 16;
-#define FREQ_LO (87 * 16000)
-#define FREQ_HI (108 * 16000)
-
-#define FREQ_IF 171200 /* 10.7*16000 */
-#define FREQ_STEP 200/* 12.5*16 */
-
-/* (x==fmhz*16*1000) - bits */
-#define FREQ2BITS(x) \
- unsigned int)(x) + FREQ_IF + (FREQ_STEP 1)) / (FREQ_STEP 2))
2)
-
-#define BITS2FREQ(x) ((x) * FREQ_STEP - FREQ_IF)
+static atomic_t maxiradio_instance = ATOMIC_INIT(0);
+#define PCI_VENDOR_ID_GUILLEMOT 0x5046
+#define PCI_DEVICE_ID_GUILLEMOT_MAXIRADIO 0x1001
struct maxiradio
{
+ struct snd_tea575x tea;
struct v4l2_device v4l2_dev;
- struct video_device vdev;
struct pci_dev *pdev;
u16 io; /* base of radio io */
- u16 muted; /* VIDEO_AUDIO_MUTE */
- u16 stereo; /* VIDEO_TUNER_STEREO_ON */
- u16 tuned; /* signal strength (0 or 0x) */
-
- unsigned long freq;
-
- struct mutex lock;
};
static inline struct maxiradio *to_maxiradio(struct v4l2_device *v4l2_dev)
@@ -110,259 +80,41 @@ static inline struct maxiradio *to_maxiradio(struct
v4l2_device *v4l2_dev)
return container_of(v4l2_dev, struct maxiradio, v4l2_dev);
}
-static void outbit(unsigned long bit, u16 io)
-{
- int val = power | wren | (bit ? data : 0);
-
- outb(val, io);
- udelay(4);
- outb(val | clk, io);
- udelay(4);
- outb(val, io);
- udelay(4);
-}
-
-static void turn_power(struct maxiradio *dev, int p)
-{
- if (p != 0) {
- dprintk(dev, 1, Radio powered on\n);
- outb(power, dev-io);
- } else {
- dprintk(dev, 1, Radio powered off\n);
- outb(0, dev-io);
- }
-}
-
-static void set_freq(struct maxiradio *dev, u32 freq)
-{
- unsigned long int si;
- int bl;
- int io = dev-io;
- int val = FREQ2BITS(freq);
-
- /* TEA5757 shift register bits (see pdf) */
-
- outbit(0, io); /* 24 search */
- outbit(1, io); /* 23 search up/down */
-
- outbit(0, io); /* 22 stereo/mono */
-
- outbit(0, io); /* 21 band */
- outbit(0, io); /* 20 band (only 00=FM works I think) */
-
- outbit(0, io); /* 19 port ? */
- outbit(0, io); /* 18 port ? */
-
- outbit(0, io); /* 17 search level */
- outbit(0, io); /* 16 search level */
-
- si = 0x8000;
- for (bl = 1; bl = 16; bl++) {
-
tea575x-tuner improvements use in maxiradio
These patches improve the tea575x-tuner module to make it up to date with the latest V4L2 frameworks. The maxiradio driver has also been converted to use the tea575x-tuner and I've used that card to test it. Unfortunately, this card can't read the data pin, so the new hardware seek functionality has been tested only partially (yes, it seeks, but when it finds a channel I can't read back the frequency). Ondrej, are you able to test these patches for the sound cards that use this tea575x tuner? Note that these two patches rely on other work that I did and that hasn't been merged yet. So it is best to pull from my git tree: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/radio-pci2 You can use the v4l-utils repository (http://git.linuxtv.org/v4l-utils.git) to test the drivers: the v4l2-compliance test should succeed and with v4l2-ctl you can test the hardware seek: To seek down: v4l2-ctl -d /dev/radio0 --freq-seek=dir=0 To seek up: v4l2-ctl -d /dev/radio0 --freq-seek=dir=1 To do the compliance test: v4l2-compliance -r /dev/radio0 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
[RFCv1 PATCH 1/2] tea575x-tuner: update to latest V4L2 framework requirements.
From: Hans Verkuil hans.verk...@cisco.com
The tea575x-tuner module has been updated to use the latest V4L2 framework
functionality. This also required changes in the drivers that rely on it.
The tea575x changes are:
- The drivers must provide a v4l2_device struct to the tea module.
- The radio_nr module parameter must be part of the actual radio driver,
and not of the tea module.
- Changed the frequency range to the normal 76-108 MHz range instead of
50-150.
- Add hardware frequency seek support.
- Fix broken rxsubchans/audmode handling.
- The application can now select between stereo and mono.
- Support polling for control events.
- Add V4L2 priority handling.
And radio-sf16fmr2.c now uses the isa bus kernel framework.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/radio/radio-sf16fmr2.c | 56 -
include/sound/tea575x-tuner.h|6 +-
sound/i2c/other/tea575x-tuner.c | 143 ++
sound/pci/es1968.c | 15
sound/pci/fm801.c| 20 -
5 files changed, 165 insertions(+), 75 deletions(-)
diff --git a/drivers/media/radio/radio-sf16fmr2.c
b/drivers/media/radio/radio-sf16fmr2.c
index 2dd4859..772a886 100644
--- a/drivers/media/radio/radio-sf16fmr2.c
+++ b/drivers/media/radio/radio-sf16fmr2.c
@@ -11,14 +11,20 @@
#include linux/init.h/* Initdata */
#include linux/ioport.h /* request_region */
#include linux/io.h /* outb, outb_p */
+#include linux/isa.h
#include sound/tea575x-tuner.h
MODULE_AUTHOR(Ondrej Zary);
MODULE_DESCRIPTION(MediaForte SF16-FMR2 FM radio card driver);
MODULE_LICENSE(GPL);
+static int radio_nr = -1;
+module_param(radio_nr, int, 0444);
+MODULE_PARM_DESC(radio_nr, Radio device number);
+
struct fmr2 {
int io;
+ struct v4l2_device v4l2_dev;
struct snd_tea575x tea;
struct v4l2_ctrl *volume;
struct v4l2_ctrl *balance;
@@ -180,26 +186,45 @@ static int fmr2_tea_ext_init(struct snd_tea575x *tea)
return 0;
}
-static int __init fmr2_init(void)
+static int __init fmr2_probe(struct device *pdev, unsigned int dev)
{
struct fmr2 *fmr2 = fmr2_card;
+ int err;
+
+ fmr2 = kzalloc(sizeof(*fmr2), GFP_KERNEL);
+ if (fmr2 == NULL)
+ return -ENOMEM;
+ strlcpy(fmr2-v4l2_dev.name, dev_name(pdev),
+ sizeof(fmr2-v4l2_dev.name));
fmr2-io = FMR2_PORT;
- if (!request_region(fmr2-io, 2, SF16-FMR2)) {
+ if (!request_region(fmr2-io, 2, fmr2-v4l2_dev.name)) {
printk(KERN_ERR radio-sf16fmr2: I/O port 0x%x already in
use\n, fmr2-io);
+ kfree(fmr2);
return -EBUSY;
}
+ err = v4l2_device_register(NULL, fmr2-v4l2_dev);
+ if (err 0) {
+ v4l2_err(fmr2-v4l2_dev, Could not register v4l2_device\n);
+ release_region(fmr2-io, 2);
+ kfree(fmr2);
+ return err;
+ }
+ fmr2-tea.v4l2_dev = fmr2-v4l2_dev;
fmr2-tea.private_data = fmr2;
+ fmr2-tea.radio_nr = radio_nr;
fmr2-tea.ops = fmr2_tea_ops;
fmr2-tea.ext_init = fmr2_tea_ext_init;
strlcpy(fmr2-tea.card, SF16-FMR2, sizeof(fmr2-tea.card));
- strcpy(fmr2-tea.bus_info, ISA);
+ snprintf(fmr2-tea.bus_info, sizeof(fmr2-tea.bus_info), ISA:%s,
+ fmr2-v4l2_dev.name);
if (snd_tea575x_init(fmr2-tea)) {
printk(KERN_ERR radio-sf16fmr2: Unable to detect TEA575x
tuner\n);
release_region(fmr2-io, 2);
+ kfree(fmr2);
return -ENODEV;
}
@@ -207,12 +232,33 @@ static int __init fmr2_init(void)
return 0;
}
-static void __exit fmr2_exit(void)
+static int __exit fmr2_remove(struct device *pdev, unsigned int dev)
{
- struct fmr2 *fmr2 = fmr2_card;
+ struct fmr2 *fmr2 = dev_get_drvdata(pdev);
snd_tea575x_exit(fmr2-tea);
release_region(fmr2-io, 2);
+ v4l2_device_unregister(fmr2-v4l2_dev);
+ kfree(fmr2);
+ return 0;
+}
+
+struct isa_driver fmr2_driver = {
+ .probe = fmr2_probe,
+ .remove = fmr2_remove,
+ .driver = {
+ .name = radio-sf16fmr2,
+ },
+};
+
+static int __init fmr2_init(void)
+{
+ return isa_register_driver(fmr2_driver, 1);
+}
+
+static void __exit fmr2_exit(void)
+{
+ isa_unregister_driver(fmr2_driver);
}
module_init(fmr2_init);
diff --git a/include/sound/tea575x-tuner.h b/include/sound/tea575x-tuner.h
index 726e947..ec3f910 100644
--- a/include/sound/tea575x-tuner.h
+++ b/include/sound/tea575x-tuner.h
@@ -25,6 +25,7 @@
#include linux/videodev2.h
#include media/v4l2-ctrls.h
#include media/v4l2-dev.h
+#include media/v4l2-device.h
#define TEA575X_FMIF 10700
@@ -42,13 +43,16 @@ struct snd_tea575x_ops {
};
[RFCv1 PATCH 2/2] radio-maxiradio: use the tea575x framework.
From: Hans Verkuil hans.verk...@cisco.com
This card is based on the tea575x receiver. Use the tea575x-tuner framework
instead of reinventing the wheel.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/radio/Kconfig |2 +-
drivers/media/radio/radio-maxiradio.c | 379 ++---
2 files changed, 65 insertions(+), 316 deletions(-)
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 48747df..6591f8b 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -43,7 +43,7 @@ config USB_DSBR
config RADIO_MAXIRADIO
tristate Guillemot MAXI Radio FM 2000 radio
- depends on VIDEO_V4L2 PCI
+ depends on VIDEO_V4L2 PCI SND
---help---
Choose Y here if you have this radio card. This card may also be
found as Gemtek PCI FM.
diff --git a/drivers/media/radio/radio-maxiradio.c
b/drivers/media/radio/radio-maxiradio.c
index f872a54..740a3d5 100644
--- a/drivers/media/radio/radio-maxiradio.c
+++ b/drivers/media/radio/radio-maxiradio.c
@@ -42,67 +42,37 @@
#include linux/videodev2.h
#include linux/io.h
#include linux/slab.h
+#include sound/tea575x-tuner.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
-
-#define DRIVER_VERSION 0.7.8
-
+#include media/v4l2-fh.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-event.h
MODULE_AUTHOR(Dimitromanolakis Apostolos, ap...@grecian.net);
-MODULE_DESCRIPTION(Radio driver for the Guillemot Maxi Radio FM2000 radio.);
+MODULE_DESCRIPTION(Radio driver for the Guillemot Maxi Radio FM2000.);
MODULE_LICENSE(GPL);
-MODULE_VERSION(DRIVER_VERSION);
+MODULE_VERSION(1.0.0);
static int radio_nr = -1;
-module_param(radio_nr, int, 0);
-
-static int debug;
-
-module_param(debug, int, 0644);
-MODULE_PARM_DESC(debug, activates debug info);
-
-#define dprintk(dev, num, fmt, arg...) \
- v4l2_dbg(num, debug, dev-v4l2_dev, fmt, ## arg)
-
-#ifndef PCI_VENDOR_ID_GUILLEMOT
-#define PCI_VENDOR_ID_GUILLEMOT 0x5046
-#endif
-
-#ifndef PCI_DEVICE_ID_GUILLEMOT
-#define PCI_DEVICE_ID_GUILLEMOT_MAXIRADIO 0x1001
-#endif
-
+module_param(radio_nr, int, 0644);
+MODULE_PARM_DESC(radio_nr, Radio device number);
/* TEA5757 pin mappings */
static const int clk = 1, data = 2, wren = 4, mo_st = 8, power = 16;
-#define FREQ_LO(87 * 16000)
-#define FREQ_HI(108 * 16000)
-
-#define FREQ_IF 171200 /* 10.7*16000 */
-#define FREQ_STEP 200/* 12.5*16 */
-
-/* (x==fmhz*16*1000) - bits */
-#define FREQ2BITS(x) \
- unsigned int)(x) + FREQ_IF + (FREQ_STEP 1)) / (FREQ_STEP 2)) 2)
-
-#define BITS2FREQ(x) ((x) * FREQ_STEP - FREQ_IF)
+static atomic_t maxiradio_instance = ATOMIC_INIT(0);
+#define PCI_VENDOR_ID_GUILLEMOT 0x5046
+#define PCI_DEVICE_ID_GUILLEMOT_MAXIRADIO 0x1001
struct maxiradio
{
+ struct snd_tea575x tea;
struct v4l2_device v4l2_dev;
- struct video_device vdev;
struct pci_dev *pdev;
u16 io; /* base of radio io */
- u16 muted; /* VIDEO_AUDIO_MUTE */
- u16 stereo; /* VIDEO_TUNER_STEREO_ON */
- u16 tuned; /* signal strength (0 or 0x) */
-
- unsigned long freq;
-
- struct mutex lock;
};
static inline struct maxiradio *to_maxiradio(struct v4l2_device *v4l2_dev)
@@ -110,259 +80,41 @@ static inline struct maxiradio *to_maxiradio(struct
v4l2_device *v4l2_dev)
return container_of(v4l2_dev, struct maxiradio, v4l2_dev);
}
-static void outbit(unsigned long bit, u16 io)
-{
- int val = power | wren | (bit ? data : 0);
-
- outb(val, io);
- udelay(4);
- outb(val | clk, io);
- udelay(4);
- outb(val, io);
- udelay(4);
-}
-
-static void turn_power(struct maxiradio *dev, int p)
-{
- if (p != 0) {
- dprintk(dev, 1, Radio powered on\n);
- outb(power, dev-io);
- } else {
- dprintk(dev, 1, Radio powered off\n);
- outb(0, dev-io);
- }
-}
-
-static void set_freq(struct maxiradio *dev, u32 freq)
-{
- unsigned long int si;
- int bl;
- int io = dev-io;
- int val = FREQ2BITS(freq);
-
- /* TEA5757 shift register bits (see pdf) */
-
- outbit(0, io); /* 24 search */
- outbit(1, io); /* 23 search up/down */
-
- outbit(0, io); /* 22 stereo/mono */
-
- outbit(0, io); /* 21 band */
- outbit(0, io); /* 20 band (only 00=FM works I think) */
-
- outbit(0, io); /* 19 port ? */
- outbit(0, io); /* 18 port ? */
-
- outbit(0, io); /* 17 search level */
- outbit(0, io); /* 16 search level */
-
- si = 0x8000;
- for (bl = 1; bl = 16; bl++) {
- outbit(val si, io);
- si = 1;
- }
-
- dprintk(dev, 1, Radio freq set to %d.%02d MHz\n,
- freq / 16000,
- freq % 16000 * 100 / 16000);
-
-
Re: [Q] Interleaved formats on the media bus
Hi Sylwester, On Saturday 04 February 2012 18:00:10 Sylwester Nawrocki wrote: On 02/04/2012 12:34 PM, Laurent Pinchart wrote: On Thursday 02 February 2012 12:14:08 Sylwester Nawrocki wrote: On 02/02/2012 10:55 AM, Laurent Pinchart wrote: Do all those sensors interleave the data in the same way ? This sounds quite No, each one uses it's own interleaving method. hackish and vendor-specific to me, I'm not sure if we should try to generalize that. Maybe vendor-specific media bus format codes would be the way to go. I don't expect ISPs to understand the format, they will likely be configured in pass-through mode. Instead of adding explicit support for all those weird formats to all ISP drivers, it might make sense to add a binary blob media bus code to be used by the ISP. This could work, except that there is no way to match a fourcc with media bus code. Different fourcc would map to same media bus code, making it impossible for the brigde to handle multiple sensors or one sensor supporting multiple interleaved formats. Moreover there is a need to map media bus code to the MIPI-CSI data ID. What if one sensor sends binary blob with MIPI-CSI User Define Data 1 and the other with User Define Data 2 ? My gut feeling is that the information should be retrieved from the sensor driver. This is all pretty vendor-specific, and adding explicit support for such sensors to each bridge driver wouldn't be very clean. Could the bridge We have many standard pixel codes in include/linux/v4l2-mediabus.h, yet each bridge driver supports only a subset of them. I wouldn't expect a sudden need for all existing bridge drivers to support some strange interleaved image formats. Those media bus codes are standard, so implementing explicit support for them in bridge drivers is fine with me. What I want to avoid is adding explicit support for sensor-specific formats to bridges. There should be no dependency between the bridge and the sensor. query the sensor using a subdev operation ? There is also a MIPI-CSI2 receiver in between that needs to be configured. I.e. it must know that it processes the User Defined Data 1, which implies certain pixel alignment, etc. So far a media bus pixel codes have been a base information to handle such things. For CSI user-defined data types, I still think that the information required to configure the CSI receiver should come from the sensor. Only the sensor knows what user-defined data type it will generate. Maybe we could create e.g. V4L2_MBUS_FMT_USER?, for each MIPI-CSI User Defined data identifier, but as I remember it was decided not to map MIPI-CSI data codes directly onto media bus pixel codes. Would setting the format directly on the sensor subdev be an option ? Do you mean setting a MIPI-CSI2 format ? No, I mean setting the media bus code on the sensor output pad to a vendor- specific value. It should work as long as the bridge driver can identify media bus code given a fourcc. I can't recall situation where a reverse lookup is necessary, i.e. struct v4l2_mbus_framefmt::code - fourcc. This would fail since e.g. JPEG and YUV/JPEG would both correspond to User 1 format. -- Regards, Laurent Pinchart -- 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: [BUG] v3.2.1: circular locking dvb_device_open / videobuf_dvb_find_frontend
Hi Linus!
The problem still exists in 3.2.4, but nobody seems to be interested ...
cu,
Knut
Am 18.01.2012 19:25, schrieb Knut Petersen:
System
==
AOpen i915GMm-hfs mobo with Pentium-M (Dothan) and 2GB
distribution: openSuSE 12.1
kernel: v3.2.1 (commit b8ed9e5b8c34dc9...)
xorg: current git master
kaffeine: 1.2.2
reproducibility: 100%
After installation of a Hauppauge WinTV Nova HD-S2
I see the following kernel info:
[ 11.528283] udevd[390]: starting version 173
[ 12.493113] Linux video capture interface: v2.00
[ 12.897710] IR NEC protocol handler initialized
[ 13.018103] IR RC5(x) protocol handler initialized
[ 13.119275] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.9 loaded
[ 13.131005] cx88/0: cx2388x v4l2 driver version 0.0.9 loaded
[ 13.137251] cx88[0]: subsystem: 0070:6906, board: Hauppauge
WinTV-HVR4000(Lite) DVB-S/S2 [card=69,autodetected], frontend(s): 1
[ 13.141210] cx88[0]: TV tuner type -1, Radio tuner type -1
[ 13.201058] IR RC6 protocol handler initialized
[ 13.261732] IR JVC protocol handler initialized
[ 13.393637] i2c-core: driver [tuner] using legacy suspend method
[ 13.409331] IR Sony protocol handler initialized
[ 13.420037] i2c-core: driver [tuner] using legacy resume method
[ 13.450185] IR MCE Keyboard/mouse protocol handler initialized
[ 13.540261] tveeprom 17-0050: Hauppauge model 69100, rev B4C3, serial# 7900937
[ 13.543914] tveeprom 17-0050: MAC address is 00:0d:fe:78:8f:09
[ 13.547637] tveeprom 17-0050: tuner model is Conexant CX24118A (idx 123, type
4)
[ 13.551355] tveeprom 17-0050: TV standards ATSC/DVB Digital (eeprom 0x80)
[ 13.554965] tveeprom 17-0050: audio processor is None (idx 0)
[ 13.558488] tveeprom 17-0050: decoder processor is CX880 (idx 20)
[ 13.561975] tveeprom 17-0050: has no radio, has IR receiver, has no IR
transmitter
[ 13.565472] cx88[0]: hauppauge eeprom: model=69100
[ 13.587102] cx2388x alsa driver version 0.0.9 loaded
[ 13.608928] lirc_dev: IR Remote Control driver registered, major 251
[ 13.694230] IR LIRC bridge handler initialized
[ 13.709152] snd_hda_intel :00:1b.0: PCI INT A - GSI 16 (level, low) -
IRQ 16
[ 13.716593] snd_hda_intel :00:1b.0: irq 46 for MSI/MSI-X
[ 13.716655] snd_hda_intel :00:1b.0: setting latency timer to 64
[ 13.724033] Registered IR keymap rc-hauppauge
[ 13.742601] input: cx88 IR (Hauppauge WinTV-HVR400 as
/devices/pci:00/:00:1e.0/:05:05.2/rc/rc0/input5
[ 13.751082] rc0: cx88 IR (Hauppauge WinTV-HVR400 as
/devices/pci:00/:00:1e.0/:05:05.2/rc/rc0
[ 13.774993] input: MCE IR Keyboard/Mouse (cx88xx) as
/devices/virtual/input/input6
[ 13.782063] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at
minor = 0
[ 13.787629] cx88[0]/2: cx2388x 8802 Driver Manager
[ 13.793692] cx88-mpeg driver manager :05:05.2: PCI INT A - GSI 17 (level,
low) - IRQ 17
[ 13.800770] cx88[0]/2: found at :05:05.2, rev: 5, irq: 17, latency: 32,
mmio: 0xd300
[ 13.818585] cx8800 :05:05.0: PCI INT A - GSI 17 (level, low) - IRQ 17
[ 13.828935] input: HDA Digital PCBeep as
/devices/pci:00/:00:1b.0/input/input7
[ 13.834870] cx88[0]/0: found at :05:05.0, rev: 5, irq: 17, latency: 32,
mmio: 0xd100
[ 13.844582] cx88[0]/0: registered device video0 [v4l2]
[ 13.861254] cx88[0]/0: registered device vbi0
[ 13.883504] snd_rme96 :05:04.0: PCI INT A - GSI 16 (level, low) - IRQ 16
[ 13.891201] cx88/2: cx2388x dvb driver version 0.0.9 loaded
[ 13.896111] cx88/2: registering cx8802 driver, type: dvb access: shared
[ 13.899622] cx88[0]/2: subsystem: 0070:6906, board: Hauppauge
WinTV-HVR4000(Lite) DVB-S/S2 [card=69]
[ 13.910340] cx88_audio :05:05.1: PCI INT A - GSI 17 (level, low) - IRQ 17
[ 13.914069] cx88[0]/2: cx2388x based DVB/ATSC card
[ 13.917646] cx8802_alloc_frontends() allocating 1 frontend(s)
[ 13.924218] cx88[0]/1: CX88x/0: ALSA support for cx2388x boards
[ 13.999524] DVB: registering new adapter (cx88[0])
[ 14.004892] DVB: registering adapter 0 frontend 0 (Conexant CX24116/CX24118)...
[...]
[ 143.850012]
[ 143.850019] ==
[ 143.850027] [ INFO: possible circular locking dependency detected ]
[ 143.850036] 3.2.1-main #19
[ 143.850040] ---
[ 143.850048] kaffeine/3749 is trying to acquire lock:
[ 143.850055] (fe-lock){+.+.+.}, at: [f86ba0cf]
videobuf_dvb_find_frontend+0x16/0x3e [videobuf_dvb]
[ 143.850074]
[ 143.850075] but task is already holding lock:
[ 143.850082] (minor_rwsem#2){..}, at: [f9de10c8]
dvb_device_open+0x24/0x185 [dvb_core]
[ 143.850102]
[ 143.850103] which lock already depends on the new lock.
[ 143.850105]
[ 143.850113]
[ 143.850114] the existing dependency chain (in reverse order) is:
[ 143.850123]
[ 143.850124] - #2 (minor_rwsem#2){..}:
[ 143.850135] [c0148809] lock_acquire+0x45/0x5c
[ 143.850148] [c043850b] down_write+0x1b/0x36
[ 143.850158] [f9de151c] dvb_register_device+0x10e/0x1e8 [dvb_core]
[ 143.850173] [f9de777d]
Re: [PATCH 05/15] mm: compaction: export some of the functions
On Fri, Feb 3, 2012 at 8:18 PM, Marek Szyprowski m.szyprow...@samsung.com wrote: From: Michal Nazarewicz min...@mina86.com This commit exports some of the functions from compaction.c file outside of it adding their declaration into internal.h header file so that other mm related code can use them. This forced compaction.c to always be compiled (as opposed to being compiled only if CONFIG_COMPACTION is defined) but as to avoid introducing code that user did not ask for, part of the compaction.c is now wrapped in on #ifdef. On Sun, 05 Feb 2012 08:40:08 +0100, Hillf Danton dhi...@gmail.com wrote: What if both compaction and CMA are not enabled? What about it? If both are enabled, both will be compiled and usable. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/15] mm: mmzone: MIGRATE_CMA migration type added
+static inline bool migrate_async_suitable(int migratetype) On Fri, 03 Feb 2012 15:19:54 +0100, Hillf Danton dhi...@gmail.com wrote: Just nitpick, since the helper is not directly related to what async means, how about migrate_suitable(int migrate_type) ? 2012/2/3 Michal Nazarewicz min...@mina86.com: I feel current name is better suited since it says that it's OK to scan this block if it's an asynchronous compaction run. On Sat, 04 Feb 2012 10:09:02 +0100, Hillf Danton dhi...@gmail.com wrote: The input is the migrate type of page considered, and the async is only one of the modes that compaction should be carried out. Plus the helper is also used in other cases where async is entirely not concerned. That said, the naming is not clear, if not misleading. In the first version the function was called is_migrate_cma_or_movable() which described what the function checked. Mel did not like it though, hence the change to migrate_async_suitable(). Honestly, I'm not sure what would be the best name for function. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
On Sat, Feb 4, 2012 at 5:43 AM, Sakari Ailus sakari.ai...@iki.fi wrote: Hi Rob, Clark, Rob wrote: On Mon, Jan 30, 2012 at 4:01 PM, Sakari Ailus sakari.ai...@iki.fi wrote: So to summarize I understand your constraints - gpu drivers have worked like v4l a few years ago. The thing I'm trying to achieve with this constant yelling is just to raise awereness for these issues so that people aren't suprised when drm starts pulling tricks on dma_bufs. I think we should be able to mark dma_bufs non-relocatable so also DRM can work with these buffers. Or alternatively, as Laurent proposed, V4L2 be prepared for moving the buffers around. Are there other reasons to do so than paging them out of system memory to make room for something else? fwiw, from GPU perspective, the DRM device wouldn't be actively relocating buffers just for the fun of it. I think it is more that we want to give the GPU driver the flexibility to relocate when it really needs to. For example, maybe user has camera app running, then puts it in the background and opens firefox which tries to allocate a big set of pixmaps putting pressure on GPU memory.. I guess the root issue is who is doing the IOMMU programming for the camera driver. I guess if this is something built in to the camera driver then when it calls dma_buf_map() it probably wants some hint that the backing pages haven't moved so in the common case (ie. buffer hasn't moved) it doesn't have to do anything expensive. On omap4 v4l2+drm example I have running, it is actually the DRM driver doing the IOMMU programming.. so v4l2 camera really doesn't need to care about it. (And the IOMMU programming here is pretty This part sounds odd to me. Well, I guess it _could_ be done that way, but the ISP IOMMU could be as well different as the one in DRM. That's the case on OMAP 3, for example. Yes, this is a difference between OMAP4 and OMAP3.. although I think the intention is that OMAP3 type scenarios, if the IOMMU mapping was done through the dma mapping API, then it could still be done (and cached) by the exporter. fast.) But I suppose this maybe doesn't represent all cases. I suppose if a camera didn't really sit behind an IOMMU but uses something more like a DMA descriptor list would want to know if it needed to regenerate it's descriptor list. Or likewise if camera has an IOMMU that isn't really using the IOMMU framework (although maybe that is easier to solve). But I think a hint returned from dma_buf_map() would do the job? An alternative to IOMMU I think in practice would mean CMA-allocated buffers. I need to think about this a bit and understand how this would really work to properly comment this. For example, how does one mlock() something that isn't mapped to process memory --- think of a dma buffer not mapped to the user space process address space? The scatter list that the exporter gives you should be locked/pinned already so importer should not need to call mlock() BR, -R Cheers, -- 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: [BUG] v3.2.1: circular locking dvb_device_open / videobuf_dvb_find_frontend
On Sun, Feb 05, 2012 at 02:33:43PM +0100, Knut Petersen wrote: Hi Linus! The problem still exists in 3.2.4, but nobody seems to be interested ... Isn't it resolved in 3.3-rc2 already? If not, please work with the linux-media developers. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TBS 6920 remote
On Fri, 3 Feb 2012 17:28:59 + Simon Jones sijones2...@gmail.com wrote: On 3 February 2012 17:12, Tony Houghton h...@realh.co.uk wrote: I've got a TBS 6920 PCI-E DVB-S2 card, which explicitly claims Linux compatibility on the box. It works as a satellite receiver, but I get no response from the remote control (trying to read /dev/input/event5). I think this is its entry in /proc/bus/input/devices: TBS have there own media tree for their cards, they do not submit the drivers upstream for inclusion in the kernel, if you go to the manufacturer site you'll get support from their forums. But it has been very well known they have issues with remote support. Thanks. It seems that there was a bug in their driver which prevented some keys from working, but AFIACT it's fixed now. The code is GPL so is it just lack of interest/demand that's stopped it from going into the main kernel? I think I'll pass on having to maintain a 3rd party driver whenever the Debian kernel upgrades. The remote is missing some quite important keys like Play, so they seem to have only considered it for live viewing, not for PVRs. I'll probably end up buying a separate USB remote or continuing to use a portable keyboard. -- 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
[ANN] Notes on the control classes and new camera controls on #v4l2-meeting 2012-02-03
Hi all, We had an IRC discussion (Sakari, Laurent and me) regarding the control classes in general and new controls that are required by more advanced camera sensors [3] (usually running a customizable firmware). More details on the agenda can be found in the invitation message [1]. There was an agreement on selected topics however some issues remain more or less open. The full meeting log can be found at [2]. The conclusions from the meeting could be summarized as follows: - We are having multiple levels of controls that interact with each other, on the lowest level are controls that are directly mapped to hardware blocks - analogue gain for example; on the highest level are controls that influence complex software algorithms implemented in a firmware; The control classes are not much helpful in logical classification of the various level controls, it is often difficult to clearly associate particular control with specific class. Therefore the controls [3] documentation should talk about of some sort of profile indicating which controls to expose on which kind of device. - The selection API should be used for specifying window-of-interest for auto focus, exposure and white balance algorithms; - We're going to use separate selection target base for AF, AE, AWB and reserve a pull of targets for each of them, e.g. 256; - A bitmask control can be used to determine which of multiple rectangles are currently in use; - In order to associate the selection targets with specific controls (AF, AE, AWB) the queryctrl ioctl may be extended to return the selection target base with the above mentioned bitmask control. The number of bits in the control will indicate maximum number of selection targets for each algorithm; - Single point coordinates, where needed, should be specified by rectangle width and height set to 0. - Control names should not generally be prefixed with a control class name, as it is not always clear which class a control should belong to; - As there is no better alternative solution it has been initially agreed to keep two new control classes: the image source and image processing class [4]; [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg42735.html [2] http://www.retiisi.org.uk/v4l2/notes/v4l2-control-classes-camera-2012-02-03.txt [3] http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/camera-controls [4] http://www.mail-archive.com/linux-media@vger.kernel.org/msg42823.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg42802.html -- Regards, Sylwester -- 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:Sun Feb 5 19:00:17 CET 2012 git hash:59b30294e14fa6a370fdd2bc2921cca1f977ef16 gcc version: i686-linux-gcc (GCC) 4.6.2 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS 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: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-rc1-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-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Re: linux-next: Tree for Feb 2 (media/radio/wl128x)
On 02/02/2012 10:20 AM, Manjunatha Halli wrote: On 02/02/2012 12:40 PM, Randy Dunlap wrote: On 02/02/2012 09:20 AM, Manjunatha Halli wrote: Hi Randy Dunlap, In config file you are missing the CONFIG_TI_ST config which builds the TI's shared transport driver upon which the FM driver works. Please select this config in drivers/misc/ti-st/Kconfig which will solve the problem. Wrong answer. The problem seems to be that GPIOLIB is not enabled, but wl128x Kconfig says: config RADIO_WL128X tristate Texas Instruments WL128x FM Radio depends on VIDEO_V4L2 RFKILL select TI_ST if NET GPIOLIB so TI_ST is not selected here. The Kconfig files should handle this properly. Here is one possible fix for you to consider. --- From: Randy Dunlaprdun...@xenotime.net Fix build errors when GPIOLIB is not enabled. Fix wl128x Kconfig to depend on GPIOLIB since TI_ST also depends on GPIOLIB. (.text+0xe6d60): undefined reference to `st_register' (.text+0xe7016): undefined reference to `st_unregister' (.text+0xe70ce): undefined reference to `st_unregister' Signed-off-by: Randy Dunlaprdun...@xenotime.net Cc: Manjunatha Hallimanjunatha_ha...@ti.com --- drivers/media/radio/wl128x/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux-next-20120202.orig/drivers/media/radio/wl128x/Kconfig +++ linux-next-20120202/drivers/media/radio/wl128x/Kconfig @@ -4,8 +4,8 @@ menu Texas Instruments WL128x FM driver (ST based) config RADIO_WL128X tristate Texas Instruments WL128x FM Radio -depends on VIDEO_V4L2 RFKILL -select TI_ST if NET GPIOLIB +depends on VIDEO_V4L2 RFKILL GPIOLIB +select TI_ST if NET help Choose Y here if you have this FM radio chip. Regards Manju On 02/02/2012 12:07 PM, Randy Dunlap wrote: On 02/01/2012 07:45 PM, Stephen Rothwell wrote: Hi all, Changes since 20120201: drivers/built-in.o: In function `fmc_prepare': (.text+0xe6d60): undefined reference to `st_register' drivers/built-in.o: In function `fmc_prepare': (.text+0xe7016): undefined reference to `st_unregister' drivers/built-in.o: In function `fmc_release': (.text+0xe70ce): undefined reference to `st_unregister' Full randconfig file is attached. This solutions seems fine for me... My only concern is since TI_ST is already have GPIOLIB in its dependency list is it OK to have the same thing in FM driver also?. Sure, it's OK. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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: [BUG] v3.2.1: circular locking dvb_device_open / videobuf_dvb_find_frontend
Am 05.02.2012 17:40, schrieb Greg KH: On Sun, Feb 05, 2012 at 02:33:43PM +0100, Knut Petersen wrote: Isn't it resolved in 3.3-rc2 already? That problem is gone ... but TV reception is distorted in 3.3-rc2 now. I´ll have a look into that tomorrow. cu, knut -- 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
AverTV Volar HD PRO
Hello, this USB stick (07ca:a835) used to work fine with the 3.0 and 3.1 kernel series, using one of the howtos in this thread: http://forum.ubuntu-it.org/index.php/topic,384436.msg3370690.html However, there were some build errors with my current kernel 3.2.4, so I tried to update the entire media tree instead, as described here: http://git.linuxtv.org/media_build.git Unfortunately, the device doesn't work. These are the dmesg messages that appear after plugging the receiver in: usb 3-1.2: new high-speed USB device number 6 using ehci_hcd WARNING: You are using an experimental version of the media stack. As the driver is backported to an older kernel, it doesn't offer enough quality for its usage in production. Use it with care. Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): 59b30294e14fa6a370fdd2bc2921cca1f977ef16 Merge branch 'v4l_for_linus' into staging/for_v3.4 72565224609a23a60d10fcdf42f87a2fa8f7b16d [media] cxd2820r: sleep on DVB-T/T2 delivery system switch 46de20a78ae4b122b79fc02633e9a6c3d539ecad [media] anysee: fix CI init WARNING: You are using an experimental version of the media stack. As the driver is backported to an older kernel, it doesn't offer enough quality for its usage in production. Use it with care. Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): 59b30294e14fa6a370fdd2bc2921cca1f977ef16 Merge branch 'v4l_for_linus' into staging/for_v3.4 72565224609a23a60d10fcdf42f87a2fa8f7b16d [media] cxd2820r: sleep on DVB-T/T2 delivery system switch 46de20a78ae4b122b79fc02633e9a6c3d539ecad [media] anysee: fix CI init IR NEC protocol handler initialized IR RC5(x) protocol handler initialized usbcore: registered new interface driver dvb_usb_af9035 IR RC6 protocol handler initialized IR JVC protocol handler initialized IR Sony protocol handler initialized IR SANYO protocol handler initialized IR MCE Keyboard/mouse protocol handler initialized lirc_dev: IR Remote Control driver registered, major 249 IR LIRC bridge handler initialized Surprisingly, the tda18218 module doesn't load automatically (I guess it should) and loading it manually doesn't help. So the device doesn't get initialized at all and there are no messages about firmware loading. (The firmware file is in /lib/firmware, of course.) Is it possible to make the device work somehow? The receiver worked fine with older kernels (using the howto from ubuntu-it.org linked above) and the remote controller was usable as well. Andrej smime.p7s Description: Elektronický podpis S/MIME
Re: AverTV Volar HD PRO
Il 06/02/2012 00:44, Andrej Podzimek ha scritto: Hello, this USB stick (07ca:a835) used to work fine with the 3.0 and 3.1 kernel series, using one of the howtos in this thread: http://forum.ubuntu-it.org/index.php/topic,384436.msg3370690.html However, there were some build errors with my current kernel 3.2.4, so I tried to update the entire media tree instead, as described here: http://git.linuxtv.org/media_build.git Unfortunately, the device doesn't work. These are the dmesg messages that appear after plugging the receiver in: Surprisingly, the tda18218 module doesn't load automatically (I guess it should) and loading it manually doesn't help. So the device doesn't get initialized at all and there are no messages about firmware loading. (The firmware file is in /lib/firmware, of course.) Is it possible to make the device work somehow? The receiver worked fine with older kernels (using the howto from ubuntu-it.org linked above) and the remote controller was usable as well. Hi Andrej, here you can find an updated version of the af9035 patch: http://openpli.git.sourceforge.net/git/gitweb.cgi?p=openpli/openembedded;a=blob_plain;f=recipes/linux/linux-etxx00/dvb-usb-af9035.patch;hb=HEAD There are several improvements, including support for newer kernels (3.2 and 3.3) as well as the current media_build tree. I also added the missing select directives for the tda18218 and mxl5007T tuners, so the modules auto-loads correctly now. In this version there is no remote support. Please let me know if it works fine for you. Regards, Gianluca -- 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] tm6000: Don't use pointer after freeing it in tm6000_ir_fini()
* Jesper Juhl wrote: In tm6000_ir_fini() there seems to be a problem. rc_unregister_device(ir-rc); calls rc_free_device() on the pointer it is given, which frees it. Subsequently the function does: if (!ir-polling) __tm6000_ir_int_stop(ir-rc); and __tm6000_ir_int_stop() dereferences the pointer it is given, which has already been freed. and it also does: tm6000_ir_stop(ir-rc); which also dereferences the (already freed) pointer. So, it seems that the call to rc_unregister_device() should be move below the calls to __tm6000_ir_int_stop() and tm6000_ir_stop(), so those don't operate on a already freed pointer. But, I must admit that I don't know this code *at all*, so someone who knows the code should take a careful look before applying this patch. It is based purely on inspection of facts of what is beeing freed where and not at all on understanding what the code does or why. I don't even have a means to test it, so beyond testing that the change compiles it has seen no testing what-so-ever. Anyway, here's a proposed patch. Signed-off-by: Jesper Juhl j...@chaosbits.net --- drivers/media/video/tm6000/tm6000-input.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/tm6000/tm6000-input.c b/drivers/media/video/tm6000/tm6000-input.c index 7844607..859eb90 100644 --- a/drivers/media/video/tm6000/tm6000-input.c +++ b/drivers/media/video/tm6000/tm6000-input.c @@ -481,8 +481,6 @@ int tm6000_ir_fini(struct tm6000_core *dev) dprintk(2, %s\n,__func__); - rc_unregister_device(ir-rc); - if (!ir-polling) __tm6000_ir_int_stop(ir-rc); @@ -492,6 +490,7 @@ int tm6000_ir_fini(struct tm6000_core *dev) tm6000_flash_led(dev, 0); ir-pwled = 0; + rc_unregister_device(ir-rc); kfree(ir); dev-ir = NULL; -- 1.7.8.4 Reviewed-by: Thierry Reding thierry.red...@avionic-design.de pgpKQJqA04XGG.pgp Description: PGP signature
RE: [GIT PULL] davinci vpif pull request
Mauro, A gentle reminder for the pull request. Cheers, -Manju On Fri, Jan 27, 2012 at 15:43:00, Hadli, Manjunath wrote: Hi Mauro, Can you please pull the following patch for v3.3-rc1 which removes some unnecessary inclusion of machine specific header files from the main driver files? This patch has undergone sufficient review already. It is just a cleanup patch and I don't expect any functionality to break because of this. Thanks and Regards, -Manju The following changes since commit 74ea15d909b31158f9b63190a95b52bc05586d4b: Linus Torvalds (1): Merge branch 'v4l_for_linus' of git://git.kernel.org/.../mchehab/linux-media are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for-mauro-v3.3 Manjunath Hadli (1): davinci: vpif: remove machine specific header file inclusion from the driver drivers/media/video/davinci/vpif.h |2 -- drivers/media/video/davinci/vpif_display.c |2 -- include/media/davinci/vpif_types.h |2 ++ 3 files changed, 2 insertions(+), 4 deletions(-) -- 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
[BUG 3.3-rc2] Hauppauge WinTV Nova-HD-S2 broken
DVB-S TV and radio reception is broken with kernel 3.3-rc2 and kaffeine 1.2.2, it works perfectly with kernel 3.2.4. video: distorted, only 1-2 fps audio: distorted system load: significantly reduced software: kernel: 3.3-rc2 (current git master) Xorg : X.Org X Server 1.11.99.902 (1.12.0 RC 2) (current git master) dvb-fe-cx24116.fw: version 1.26.90.0 hardware: AOpen i915GMm-hfs, Pentium M Dothan, 2MHz, 2GB RAM, Hauppauge WinTV Nova-HD-S2 cu, Knut -- 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
