Re: ngene Satix-S2 dual problems
On 27 Nov 2010, at 12:15, Robert Longbottom wrote: I'm just debating whether to leave it as the active card and see how it gets on. Assuming it manages this evenings recordings ok, I think I will probably will. Well, I did leave it as the active (and only) card in my MythTV box and it's been working fine for a week now doing my usual recording schedule across both inputs. I've not seen any failed recordings, or any problems with the recordings it's made. Same here, it's been running as tuners 23 all week, I didn't report back until I'd seen a few of the recordings as I've been working away this week. So looks like it works, big thanks to Oliver. So it seems that it is working fine now. I still have the problem with the additional dvb adapters, but they don't seem to be causing a problem so far as I can tell. Yeah would be good to know what that's all about, maybe there is some additional capability in this chipset but unused in the Satix S2? Thanks go to Oliver for these drivers - hopefully we can see these changes in the kernel sometime soon :-) Seconded. Andre-- 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: gnutv: move channel_name to flag to allow piped output
On Sunday 28 November 2010 05:42:21 David Liontooth wrote: I need to capture ATSC QAM closed captioning to file, and at the same time the mpeg-ts stream to a different file. I've been looking for an app that will let me do this. A simple cat works: cat /dev/dvb/adapter0/dvr0 | tee $FIL.mpg | zvbi-atsc-cc --atsc -m -C $FIL.txt -T KCBS But there is naturally no tuner or timer in cat, so closing the processes at the end of the recording is a hassle; there may be other issues cat doesn't handle optimally. I looked around and found gnutv in the dvb-apps project. gnutv is actively maintained, tunes ATSC QAM-256, handles individual channels well, and has a timer -- but it has a small, show-stopper problem. gnutv mandates that the channel name be placed at the end of the user input. There is a great -out stdout option, but you can't use it to pipe, since the channel name has to be placed afterwards. I suggest we move the channel name into a flag, like the other user values, so that we can pipe the output like this: gnutv -adapter 0 -channel_list ~/.azap/channels.conf -timeout 10 -channel_name KCBS \ -out stdout | tee $FIL.mpg | zvbi-atsc-cc --atsc -T -9 $FIL.txt -n KCBS With a simple patch against the today's mercurial tree, as below, this works great. For clarity, I renamed channels to channels_list; I'll be happy to remove that change if it breaks too many scripts. I don't know how to make the change to channel_name so that it's backwardly compatible, but maybe we don't need to. Hm, I do not understand, why it might be a problem to have the channel name as the last parameter. What happens if you try gnutv -adapter 0 -channels ~/.azap/channels.conf -timeout 10 -out stdout KCBS | tee $FIL.mpg | zvbi-atsc-cc --atsc -T -9 $FIL.txt -n KCBS with an unpatched gnutv? CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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: ngene Satix-S2 dual problems
On Sunday 28 November 2010 09:27:03 Andre wrote: On 27 Nov 2010, at 12:15, Robert Longbottom wrote: I'm just debating whether to leave it as the active card and see how it gets on. Assuming it manages this evenings recordings ok, I think I will probably will. Well, I did leave it as the active (and only) card in my MythTV box and it's been working fine for a week now doing my usual recording schedule across both inputs. I've not seen any failed recordings, or any problems with the recordings it's made. Same here, it's been running as tuners 23 all week, I didn't report back until I'd seen a few of the recordings as I've been working away this week. So looks like it works, big thanks to Oliver. So it seems that it is working fine now. I still have the problem with the additional dvb adapters, but they don't seem to be causing a problem so far as I can tell. Yeah would be good to know what that's all about, maybe there is some additional capability in this chipset but unused in the Satix S2? You can attach a Duoflex tuner extension to Satix S2 Dual V2 or cineS2 V5.5 cards. This way you can have up to 4 tuners. Without the Duoflex the additional adapters are empty. This is a minor issue which will be fixed later. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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
Disable IR on dvb_usb_af9015
Hello list! I have a Kworld U399U twin DVB-T adapter. It has a IR rceiver and I want to disable it from module on /etc/modprobe.d/options.conf Is any way to do this? I use to use the modprobe option to assign the number of the adapters: options dvb_usb_af9015 adapter_nr=4,5 It will be great to disable the IR. Thanks for all and best regards. -- Josu Lazkano -- 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: Disable IR on dvb_usb_af9015
There is no module or per device basis option for that. Use option from module dvb-usb. Antti On 11/28/2010 02:58 PM, Josu Lazkano wrote: Hello list! I have a Kworld U399U twin DVB-T adapter. It has a IR rceiver and I want to disable it from module on /etc/modprobe.d/options.conf Is any way to do this? I use to use the modprobe option to assign the number of the adapters: options dvb_usb_af9015 adapter_nr=4,5 It will be great to disable the IR. Thanks for all and best regards. -- 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: ngene Satix-S2 dual problems
On 28 Nov 2010, at 12:53, Oliver Endriss wrote: On Sunday 28 November 2010 09:27:03 Andre wrote: On 27 Nov 2010, at 12:15, Robert Longbottom wrote: I'm just debating whether to leave it as the active card and see how it gets on. Assuming it manages this evenings recordings ok, I think I will probably will. Well, I did leave it as the active (and only) card in my MythTV box and it's been working fine for a week now doing my usual recording schedule across both inputs. I've not seen any failed recordings, or any problems with the recordings it's made. Same here, it's been running as tuners 23 all week, I didn't report back until I'd seen a few of the recordings as I've been working away this week. So looks like it works, big thanks to Oliver. So it seems that it is working fine now. I still have the problem with the additional dvb adapters, but they don't seem to be causing a problem so far as I can tell. Yeah would be good to know what that's all about, maybe there is some additional capability in this chipset but unused in the Satix S2? You can attach a Duoflex tuner extension to Satix S2 Dual V2 or cineS2 V5.5 cards. This way you can have up to 4 tuners. That's a nice idea, 4x DVBS2 in one pcie x1 slot, looks like DVBT/C options too. That seems a lot to ask from the bridge and driver, potentially having four 8PSK DVBS2 muxes delivered though it! Would be the MythTV dream system for those SFF motherboards though. Without the Duoflex the additional adapters are empty. There seems to be three extra adaptors, is the fifth one for the CI? This is a minor issue which will be fixed later. Happy to help with any testing. Andre-- 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: Disable IR on dvb_usb_af9015
Thanks for your reply. 2010/11/28 Antti Palosaari cr...@iki.fi: There is no module or per device basis option for that. Use option from module dvb-usb. Sorry, but I don't know how to use the option from module dvb-usb, I am new on this. I want to disable it, because I have problems to assign LIRC which input to choose. Kind regards. Antti On 11/28/2010 02:58 PM, Josu Lazkano wrote: Hello list! I have a Kworld U399U twin DVB-T adapter. It has a IR rceiver and I want to disable it from module on /etc/modprobe.d/options.conf Is any way to do this? I use to use the modprobe option to assign the number of the adapters: options dvb_usb_af9015 adapter_nr=4,5 It will be great to disable the IR. Thanks for all and best regards. -- http://palosaari.fi/ -- Josu Lazkano -- 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/2] bttv IR patches for Nebula Digitv
The first patch of this series is just a cleanup. It also adds a debug message that can help to change IR support for Nebula to use the RC core raw decoders. The second patch is an attempt to generate IRQ's on both 0-1 and 1-0 transitions, required for the in-kernel decoders to work. Not sure if I did it right, as the conexant datasheet[1] is not very clear about how to enable GPINTR on both transitions. If the second patch works fine, it should be easy to convert the rc5_irq code to work like the saa7134 one, and remove the old RC5 decoder from bttv driver. People with Nebula DigiTV that want to help testing it: please apply the first patch, and load the bttv driver with remote debug enabled (modprobing bttv driver with ir_debug=1), and press some keys at the IR, using the original IR (or another RC5 IR). You should see some messages printed the kernel log (dmesg command shows them), like: bttv: RC5 IRQ: gap 180 us for mark bttv: RC5 IRQ: gap 180 us for mark bttv: RC5 IRQ: gap 180 us for mark bttv: RC5 IRQ: gap 180 us for mark If this goes well, please apply the second patch, re-compile/reload the modules and you should see also messages for space, if the patch goes well, something like: bttv: RC5 IRQ: gap 180 us for mark bttv: RC5 IRQ: gap 180 us for space bttv: RC5 IRQ: gap 180 us for mark bttv: RC5 IRQ: gap 180 us for space (the actual values for the gap will be different, as they'll depend on the amount of time spent between each printed line). The patches should be applied against the latest development tree, available at: http://git.linuxtv.org/media_tree.git Another alternative to test the patches is to use the media_build tree: http://git.linuxtv.org/media_build.git The media tree allows compilation against older kernels, but the backports may not be 100%. Please test both patches and give us a feedback. If both patches are fine, I'll write a patch porting Nebula IR support to use the RC core raw decoders. [1]http://www.conexant.com/servlets/DownloadServlet/DSH-200115-001.pdf?docid=116revid=1 Mauro Carvalho Chehab (2): [media] bttv: remove custom_irq and gpioq from bttv struct [media] RFC: Enable IRQ's on both GPIO transitions drivers/media/video/bt8xx/bttv-driver.c |6 drivers/media/video/bt8xx/bttv-input.c | 41 +++--- drivers/media/video/bt8xx/bttvp.h |4 +-- 3 files changed, 27 insertions(+), 24 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
[PATCH 1/2] [media] bttv: remove custom_irq and gpioq from bttv struct
The RC5 old decoder used custom_irq to indicate the need of handling
the IRQ on a different way. Instead of doing it, let the core just call the
bttv input IRQ handler, and add the code there to call the legacy decoder.
While here, remove the gpioq waitqueue, as this is not used anywhere, and
add a debug msg to help removing the legacy RC5 code.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/bt8xx/bttv-driver.c
b/drivers/media/video/bt8xx/bttv-driver.c
index 3da6e80..97159ba 100644
--- a/drivers/media/video/bt8xx/bttv-driver.c
+++ b/drivers/media/video/bt8xx/bttv-driver.c
@@ -4153,9 +4153,6 @@ static irqreturn_t bttv_irq(int irq, void *dev_id)
btv=(struct bttv *)dev_id;
- if (btv-custom_irq)
- handled = btv-custom_irq(btv);
-
count=0;
while (1) {
/* get/clear interrupt status bits */
@@ -4191,7 +4188,6 @@ static irqreturn_t bttv_irq(int irq, void *dev_id)
btv-field_count++;
if ((astat BT848_INT_GPINT) btv-remote) {
- wake_up(btv-gpioq);
bttv_input_irq(btv);
}
@@ -4396,7 +4392,6 @@ static int __devinit bttv_probe(struct pci_dev *dev,
mutex_init(btv-lock);
spin_lock_init(btv-s_lock);
spin_lock_init(btv-gpio_lock);
- init_waitqueue_head(btv-gpioq);
init_waitqueue_head(btv-i2c_queue);
INIT_LIST_HEAD(btv-c.subs);
INIT_LIST_HEAD(btv-capture);
@@ -4584,7 +4579,6 @@ static void __devexit bttv_remove(struct pci_dev *pci_dev)
/* tell gpio modules we are leaving ... */
btv-shutdown=1;
- wake_up(btv-gpioq);
bttv_input_fini(btv);
bttv_sub_del_devices(btv-c);
diff --git a/drivers/media/video/bt8xx/bttv-input.c
b/drivers/media/video/bt8xx/bttv-input.c
index 989c048..7f48306 100644
--- a/drivers/media/video/bt8xx/bttv-input.c
+++ b/drivers/media/video/bt8xx/bttv-input.c
@@ -120,11 +120,15 @@ static void ir_enltv_handle_key(struct bttv *btv)
ir-last_gpio = data | keyup;
}
+static int bttv_rc5_irq(struct bttv *btv);
+
void bttv_input_irq(struct bttv *btv)
{
struct bttv_ir *ir = btv-remote;
- if (!ir-polling)
+ if (ir-rc5_gpio)
+ bttv_rc5_irq(btv);
+ else if (!ir-polling)
ir_handle_key(btv);
}
@@ -251,22 +255,25 @@ static int bttv_rc5_irq(struct bttv *btv)
/* read gpio port */
gpio = bttv_gpio_read(btv-c);
+ /* get time of bit */
+ current_jiffies = jiffies;
+ do_gettimeofday(tv);
+
+ /* avoid overflow with gap 1s */
+ if (tv.tv_sec - ir-base_time.tv_sec 1) {
+ gap = 20;
+ } else {
+ gap = 100 * (tv.tv_sec - ir-base_time.tv_sec) +
+ tv.tv_usec - ir-base_time.tv_usec;
+ }
+
+ dprintk(KERN_INFO DEVNAME : RC5 IRQ: gap %d us for %s\n,
+ gap, (gpio 0x20) ? mark : space);
+
/* remote IRQ? */
if (!(gpio 0x20))
return 0;
- /* get time of bit */
- current_jiffies = jiffies;
- do_gettimeofday(tv);
-
- /* avoid overflow with gap 1s */
- if (tv.tv_sec - ir-base_time.tv_sec 1) {
- gap = 20;
- } else {
- gap = 100 * (tv.tv_sec - ir-base_time.tv_sec) +
- tv.tv_usec - ir-base_time.tv_usec;
- }
-
/* active code = add bit */
if (ir-active) {
/* only if in the code (otherwise spurious IRQ or timer
@@ -479,8 +486,7 @@ int bttv_input_init(struct bttv *btv)
break;
case BTTV_BOARD_NEBULA_DIGITV:
ir_codes = RC_MAP_NEBULA;
- btv-custom_irq = bttv_rc5_irq;
- ir-rc5_gpio = 1;
+ ir-rc5_gpio = true;
break;
case BTTV_BOARD_MACHTV_MAGICTV:
ir_codes = RC_MAP_APAC_VIEWCOMP;
diff --git a/drivers/media/video/bt8xx/bttvp.h
b/drivers/media/video/bt8xx/bttvp.h
index 0712320..9b776fa 100644
--- a/drivers/media/video/bt8xx/bttvp.h
+++ b/drivers/media/video/bt8xx/bttvp.h
@@ -139,7 +139,7 @@ struct bttv_ir {
int rc5_remote_gap;
/* RC5 gpio */
- u32 rc5_gpio;
+ boolrc5_gpio; /* Is RC5 legacy GPIO enabled? */
u32 last_bit; /* last raw bit seen */
u32 code; /* raw code under construction */
struct timeval base_time; /* time of last seen code */
@@ -364,12 +364,10 @@ struct bttv {
struct bttv_pll_info pll;
int triton1;
int gpioirq;
- int (*custom_irq)(struct bttv *btv);
int use_i2c_hw;
/* old gpio interface */
- wait_queue_head_t gpioq;
int shutdown;
void (*volume_gpio)(struct bttv *btv, __u16 volume);
--
1.7.1
--
To
[PATCH 2/2] [media] RFC: Enable IRQ's on both GPIO transitions
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/bt8xx/bttv-input.c
b/drivers/media/video/bt8xx/bttv-input.c
index 7f48306..8ede256 100644
--- a/drivers/media/video/bt8xx/bttv-input.c
+++ b/drivers/media/video/bt8xx/bttv-input.c
@@ -522,6 +522,11 @@ int bttv_input_init(struct bttv *btv)
gpio = bttv_gpio_read(btv-c);
bttv_gpio_write(btv-c, gpio ~(1 4));
bttv_gpio_write(btv-c, gpio | (1 4));
+
+ /* set normal/inverted mode at GPINTR pin as irq trigger */
+ btaor(0,
+ ~(BT848_GPIO_DMA_CTL_GPINTC | BT848_GPIO_DMA_CTL_GPINTI),
+ BT848_GPIO_DMA_CTL);
} else {
/* init hardware-specific stuff */
bttv_gpio_inout(btv-c, ir-mask_keycode | ir-mask_keydown,
0);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [omap3isp RFC][RESEND PATCH v2 0/4] Improve inter subdev interaction
Hi Sergio, Thanks for the patches. I've added them to my queue, I will still need a couple of days to solve issues with the internal tree before I can apply them. -- 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: [RFC/PATCH v6 05/12] media: Reference count and power handling
Hi Mark, On Thursday 25 November 2010 22:47:09 Mark Brown wrote: On Thu, Nov 25, 2010 at 07:49:05PM +0200, Sakari Ailus wrote: Currently when two media entities are connected they will be powered up for the duration of the link setup, just in case the drivers would need to access hardware for some reason. I don't think we have a need for that at the moment, it's so just because it seemed to be the right thing to do. This is *really* bad for audio, powering things on and off needlessly can cause audible effects for users. If the individual drivers need to do something they can go and implement that but powering things up by default seems like it'll at best waste power most of the time. The OMAP3 ISP driver required entities to be powered on when link attributes were modified, but that's not true anymore. We could remove this feature, or make it optional. Essentially the idea is that the drivers do not need to be involved with the power state handling and the device would be powered always when they are run, but not be powered when it's not necessary. This is what DAPM does in ASoC at the minute. What it does is that every time there is a change in the device configuration which might have affected the power state it walks the graph of power nodes in the system. If there has been a change in the state the core will generate a power transition sequence and apply it. The devices have no knowledge of this (though they can insert manual sequences for nodes if they need to), for the most part they just describe the graph and the register bits that control the power for the nodes and the routing. Subdev is a V4L2 specific concept and I don't know if ALSA would benefit from something similar. If you want to be able to access the individual enties from user space, then similar arrangement might be useful. ALSA already has this feature (at least in the embedded case, HDA has some of these features too). I don't see a problem in applying restrictions on power on / off sequence. They would probably be useful also on the V4L2 side in the future. Could the restrictions be described as dependencies only, i.e. entity 1 power-up requires entity 2 to be powered first, also meaning that entity 2 could be powered down only after entity 1 has been powered down? No. Audio power sequencing tends to work better if sorted by the type of object rather than the route (though using the route as a lower order sort key can be useful). It's also useful to coalesce the I/O on the hardware for performance (both speed and user experience). The way we're currently doing it the sequencing is actually separated from the graph walk - the result of the graph walk is a set of things that need doing which is then implemented in a separate step. I think this would be the easiest way to integrate with what you're doing at the minute, keep the same split and then ASoC can do the postprocessing of the results of the graph walk in the same way as it does currently. Throwing an idea here, what about making power management modular ? The MC core would then call back to drivers to handle use count changes. The media_entity_use_change() function would be exported (and renamed), so that drivers could use it if they want graph-based power management. ALSA would have its own use count handler. -- 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: [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Mark, On Friday 26 November 2010 15:14:42 Mark Brown wrote: On Fri, Nov 26, 2010 at 03:13:36PM +0100, Laurent Pinchart wrote: On Thursday 25 November 2010 16:49:52 Mark Brown wrote: On Thu, Nov 25, 2010 at 04:40:41PM +0100, Laurent Pinchart wrote: It's supposed to reflect whether the link can carry data. Think of the active flag as a valve on a pipe. If the valve is open, the link is active. If the valve is closed, the link is inactive. This is unrelated to whether water actually flows through the pipe. This seems a confusing name, then - I'd expect an active link to be one which is actually carrying data rather than one which is available to carry data. How a more neutrally worded name such as connected (which is what ASoC uses currently)? In our current vocabulary connected refers to entities between which a link exist, regardless of the link state (valve opened or valve closed). I'm not totally happy with active either, but if we replace it with connected we need another word to replace current uses of connected. Linked? That's a good option. Hans, do you want to comment on this ? -- 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: [RFC/PATCH v6 03/12] media: Entities, pads and links
On Sunday, November 28, 2010 13:34:45 Laurent Pinchart wrote: Hi Mark, On Friday 26 November 2010 15:14:42 Mark Brown wrote: On Fri, Nov 26, 2010 at 03:13:36PM +0100, Laurent Pinchart wrote: On Thursday 25 November 2010 16:49:52 Mark Brown wrote: On Thu, Nov 25, 2010 at 04:40:41PM +0100, Laurent Pinchart wrote: It's supposed to reflect whether the link can carry data. Think of the active flag as a valve on a pipe. If the valve is open, the link is active. If the valve is closed, the link is inactive. This is unrelated to whether water actually flows through the pipe. This seems a confusing name, then - I'd expect an active link to be one which is actually carrying data rather than one which is available to carry data. How a more neutrally worded name such as connected (which is what ASoC uses currently)? In our current vocabulary connected refers to entities between which a link exist, regardless of the link state (valve opened or valve closed). I'm not totally happy with active either, but if we replace it with connected we need another word to replace current uses of connected. Linked? That's a good option. Hans, do you want to comment on this ? Fine by me! It's better than 'active'. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[FIX for 2.6.37]
Hi Mauro, please pull from git://github.com/pboettch/linux-2.6.git v2.6.37-fixes for flexcop-pci: sanitize driver name to avoid warning on load It fixes https://bugzilla.kernel.org/show_bug.cgi?id=15826 . thanks and best regards, -- Patrick Boettcher - KernelLabs 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
[PATCH 1/3] soc_camera: Add the ability to bind regulators to soc_camedra devices
In certain machines, camera devices are supplied directly
by a number of regulators. This patch add the ability to drive
these regulators directly by the soc_camera driver.
What the machine code have to do to use this functionality is to:
1- Define a number of useful regulator supply descriptions such as:
static struct regulator_consumer_supply camera_reg1_consumers[] = {
...
REGULATOR_SUPPLY(camera_reg1, soc-camera-pdrv.0),
...
};
(Pay attention at the .N suffix of soc-camera-pdrv in case of
a system with multiple cameras)
2- Define the list of regulators to bind to a specific instance of
soc-camera-pdrv with their voltages:
static struct soc_camera_regulator_desc soc_camera_regs[] = {
SOCAM_REG_DESC(camera_reg1, 130, 130),
SOCAM_REG_DESC(camera_reg2, 280, 280),
...
};
3- Add the list to the corresponding soc_camera_link description:
static struct soc_camera_link iclink_my_camera = {
...
.soc_regulator_descs= soc_camera_regs,
.num_soc_regulator_descs= ARRAY_SIZE(soc_camera_regs),
};
4- And register it as usual with the platform device description:
static struct platform_device machine_my_camera = {
.name = soc-camera-pdrv,
.id = 0,
.dev= {
.platform_data = iclink_my_camera,
},
};
Signed-off-by: Alberto Panizzo maramaopercheseimo...@gmail.com
---
drivers/media/video/soc_camera.c | 135 +++--
include/media/soc_camera.h | 16 +
2 files changed, 129 insertions(+), 22 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 43848a7..8fc5831 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -43,6 +43,96 @@ static LIST_HEAD(hosts);
static LIST_HEAD(devices);
static DEFINE_MUTEX(list_lock);/* Protects the list of hosts */
+static int soc_camera_setup_regulators(struct soc_camera_device *icd,
+ struct soc_camera_link *icl)
+{
+ int i, ret;
+
+ icd-soc_regulators = kzalloc(icl-num_soc_regulator_descs *
+ sizeof(struct regulator *), GFP_KERNEL);
+ if (!icd-soc_regulators) {
+ dev_err(icd-pdev, Not enough memory.\n);
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ for (i = 0; i icl-num_soc_regulator_descs; i++) {
+ dev_dbg(icd-pdev, Looking for reg:'%s' bound to dev:'%s',
+ icl-soc_regulator_descs[i].supply,
+ dev_name(icd-pdev));
+ icd-soc_regulators[i] = regulator_get(icd-pdev,
+ icl-soc_regulator_descs[i].supply);
+ if (IS_ERR(icd-soc_regulators[i])) {
+ icd-soc_regulators[i] = NULL;
+ dev_err(icd-pdev, Unable to get regulator: \%s\.\n,
+ icl-soc_regulator_descs[i].supply);
+ ret = -ENODEV;
+ goto free_regs;
+ }
+ }
+
+ icd-num_soc_regulators = icl-num_soc_regulator_descs;
+
+ return 0;
+
+free_regs:
+ for (i--; i = 0; i--)
+ regulator_put(icd-soc_regulators[i]);
+err:
+ return ret;
+}
+
+static int soc_camera_power_set(struct soc_camera_device *icd,
+ struct soc_camera_link *icl,
+ int power_on)
+{
+ int ret, i;
+
+ for (i = 0; i icd-num_soc_regulators; i++) {
+ if (power_on) {
+ ret = regulator_set_voltage(icd-soc_regulators[i],
+ icl-soc_regulator_descs[i].value_on_min,
+ icl-soc_regulator_descs[i].value_on_max);
+ if (ret) {
+ dev_err(icd-pdev, Cannot set '%s' to %d:%d,
+ icl-soc_regulator_descs[i].supply,
+ icl-soc_regulator_descs[i].value_on_min,
+ icl-soc_regulator_descs[i].value_on_max);
+ goto err;
+ }
+
+ ret = regulator_enable(icd-soc_regulators[i]);
+ if (ret 0) {
+ dev_err(icd-pdev, Cannot enable reg '%s',
+ icl-soc_regulator_descs[i].supply);
+ goto err;
+ }
+ } else {
+ ret = regulator_disable(icd-soc_regulators[i]);
+ if (ret) {
+ dev_err(icd-pdev, Cannot disable reg '%s',
+ icl-soc_regulator_descs[i].supply);
+ goto err;
+ }
+ }
+ }
+
+ if
Re: [linux-dvb] gnutv: move channel_name to flag to allow piped output
On 11/28/2010 03:40 AM, Edgar Matzinger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Dave, On 28/11/10 05:42, David Liontooth wrote: gnutv -adapter 0 -channel_list ~/.azap/channels.conf -timeout 10 -channel_name KCBS \ -out stdout | tee $FIL.mpg | zvbi-atsc-cc --atsc -T -9 $FIL.txt -n KCBS This should work: $ gnutv -adapter 0 -channel_list ~/.azap/channels.conf -timeout 10 \ -out stdout KCBS | tee $FIL.mpg | zvbi-atsc-cc --atsc -T -9 $FIL.txt \ -n KCBS Yes it does - I didn't think of trying that. Thanks to you and Oliver! -- 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/3] V4L2: Add a v4l2-subdev (soc-camera) driver for OmniVision OV2640 sensor
Signed-off-by: Alberto Panizzo maramaopercheseimo...@gmail.com --- drivers/media/video/Kconfig |6 + drivers/media/video/Makefile|1 + drivers/media/video/ov2640.c| 1153 +++ include/media/v4l2-chip-ident.h |1 + 4 files changed, 1161 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/ov2640.c diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 0efbb29..898f76f 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -807,6 +807,12 @@ config SOC_CAMERA_OV9640 help This is a ov9640 camera driver +config SOC_CAMERA_OV2640 + tristate ov2640 camera support + depends on SOC_CAMERA I2C + help + This is a ov2640 camera driver + config MX1_VIDEO bool diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index af79d47..fac185d 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -82,6 +82,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o obj-$(CONFIG_SOC_CAMERA_OV6650)+= ov6650.o obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o obj-$(CONFIG_SOC_CAMERA_OV9640)+= ov9640.o +obj-$(CONFIG_SOC_CAMERA_OV2640)+= ov2640.o obj-$(CONFIG_SOC_CAMERA_RJ54N1)+= rj54n1cb0c.o obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o diff --git a/drivers/media/video/ov2640.c b/drivers/media/video/ov2640.c new file mode 100644 index 000..5edf23e --- /dev/null +++ b/drivers/media/video/ov2640.c @@ -0,0 +1,1153 @@ +/* + * ov2640 Camera Driver + * + * Copyright (C) 2010 Alberto Panizzo maramaopercheseimo...@gmail.com + * + * Based on ov772x, ov9640 drivers and previous non merged implementations. + * + * Copyright 2005-2009 Freescale Semiconductor, Inc. All Rights Reserved. + * Copyright (C) 2006, OmniVision + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/init.h +#include linux/module.h +#include linux/i2c.h +#include linux/slab.h +#include linux/delay.h +#include linux/videodev2.h +#include media/v4l2-chip-ident.h +#include media/v4l2-subdev.h +#include media/soc_camera.h +#include media/soc_mediabus.h + +#define VAL_SET(x, mask, rshift, lshift) \ + x) rshift) mask) lshift) +/* + * DSP registers + * register offset for BANK_SEL == BANK_SEL_DSP + */ +#define R_BYPASS0x05 /* Bypass DSP */ +#define R_BYPASS_DSP_BYPAS0x01 /* Bypass DSP. sensor out directly */ +#define R_BYPASS_USE_DSP 0x00 /* Bypass DSP. sensor out directly */ +#define QS 0x44 /* Quantization Scale Factor */ +#define CTRLI 0x50 +#define CTRLI_LP_DP 0x80 +#define CTRLI_ROUND 0x40 +#define CTRLI_V_DIV_SET(x)VAL_SET(x, 0x3, 0, 3) +#define CTRLI_H_DIV_SET(x)VAL_SET(x, 0x3, 0, 0) +#define HSIZE 0x51 /* H_SIZE[7:0] (real/4) */ +#define HSIZE_SET(x) VAL_SET(x, 0xFF, 2, 0) +#define VSIZE 0x52 /* V_SIZE[7:0] (real/4) */ +#define VSIZE_SET(x) VAL_SET(x, 0xFF, 2, 0) +#define XOFFL 0x53 /* OFFSET_X[7:0] */ +#define XOFFL_SET(x) VAL_SET(x, 0xFF, 0, 0) +#define YOFFL 0x54 /* OFFSET_Y[7:0] */ +#define YOFFL_SET(x) VAL_SET(x, 0xFF, 0, 0) +#define VHYX0x55 /* Offset and size completion */ +#define VHYX_VSIZE_SET(x) VAL_SET(x, 0x1, (8+2), 7) +#define VHYX_HSIZE_SET(x) VAL_SET(x, 0x1, (8+2), 3) +#define VHYX_YOFF_SET(x) VAL_SET(x, 0x3, 8, 4) +#define VHYX_XOFF_SET(x) VAL_SET(x, 0x3, 8, 0) +#define DPRP0x56 +#define TEST0x57 /* Horizontal size completion */ +#define TEST_HSIZE_SET(x) VAL_SET(x, 0x1, (9+2), 7) +#define ZMOW0x5A /* Zoom: Out Width OUTW[7:0] (real/4) */ +#define ZMOW_OUTW_SET(x) VAL_SET(x, 0xFF, 2, 0) +#define ZMOH0x5B /* Zoom: Out Height OUTH[7:0] (real/4) */ +#define ZMOH_OUTH_SET(x) VAL_SET(x, 0xFF, 2, 0) +#define ZMHH0x5C /* Zoom: Speed and HW completion */ +#define ZMHH_ZSPEED_SET(x)VAL_SET(x, 0x0F, 0, 4) +#define ZMHH_OUTH_SET(x) VAL_SET(x, 0x1, (8+2), 2) +#define ZMHH_OUTW_SET(x) VAL_SET(x, 0x3, (8+2), 0) +#define BPADDR 0x7C /* SDE Indirect Register Access: Address */ +#define BPDATA 0x7D /* SDE Indirect Register Access: Data */ +#define CTRL2 0x86 /* DSP Module enable 2 */ +#define CTRL2_DCW_EN 0x20 +#define CTRL2_SDE_EN 0x10 +#define CTRL2_UV_ADJ_EN 0x08 +#define CTRL2_UV_AVG_EN 0x04 +#define CTRL2_CMX_EN 0x01 +#define CTRL3 0x87 /* DSP Module enable 3 */ +#define CTRL3_BPC_EN 0x80 +#define CTRL3_WPC_EN 0x40 +#define SIZEL 0x8C /* Image Size Completion */ +#define SIZEL_HSIZE8_11_SET(x) VAL_SET(x, 0x1, 11, 6)
Re: Problems with using dvb_usb_rtl2832u
On 27 November 2010 17:05, Mike Martin m...@redtux.org.uk wrote: On 27 November 2010 16:33, Anca Emanuel anca.eman...@gmail.com wrote: On Sat, Nov 27, 2010 at 6:14 PM, Mike Martin redt...@gmail.com wrote: Hi I am using this driver with USB 1b80:s395 It's not possible to be s395, please send what lsusb prints. And if you have other info, like the product info, etc. sorry typo 1b80:d395 further info Dvbstreamer works but very few other dvb* utilities - confused now -- 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
user accesses in ivtv-fileops.c:ivtv_v4l2_write ?
Hi, Sparse pointed me at the following line in ivtv-fileops.c's ivtv_v4l2_write: ivtv_write_vbi(itv, (const struct v4l2_sliced_vbi_data *)user_buf, elems); Now user_buf is a parameter: const char __user *user_buf, so that is losing the __user, and I don't see what else protects the accesses that ivtv_write_vbi performs. Is there something that makes this safe? Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \ gro.gilbert @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/ -- 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: problem af9015: tuner id:177 not supported, please report!
It is MxL5007T. Has gone to the 2.6.37. Antti On 11/28/2010 05:55 PM, helmut.neume...@gmx.de wrote: hello i have a prob lem with a tv-stick i get the error af9015: tuner id:177 not supported, please report! uname -r 2.6.32-25-generic-pae can anybody help me i have downloaded the actual source but i get the same error. -- 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/PATCH v6 05/12] media: Reference count and power handling
On 28 Nov 2010, at 12:33, Laurent Pinchart wrote: Throwing an idea here, what about making power management modular ? The MC core would then call back to drivers to handle use count changes. The media_entity_use_change() function would be exported (and renamed), so that drivers could use it if they want graph-based power management. ALSA would have its own use count handler. We need more than just the count handler - we need a complete list of everything that has been changed in the whole system. The graph walk itself is fine but we need to be able to do postprocessing of the delta that is generated. Like I said pre- and post- callbacks may well cover it. Note that this is specifically for ASoC, not ALSA in general.-- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Nov 28 19:00:12 CET 2010 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec-git: OK 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 1/3] soc_camera: Add the ability to bind regulators to soc_camedra devices
On Sun, 28 Nov 2010, Alberto Panizzo wrote:
In certain machines, camera devices are supplied directly
by a number of regulators. This patch add the ability to drive
these regulators directly by the soc_camera driver.
IIRC, there has been a discussion a while ago, how to supply power to
cameras by regulators. Someone has tried to provide a .power() hook in the
platform code, but the problem was the order of driver loading / probing.
So, how about doing the following:
1. in your platform code you register a notifier like
bus_register_notifier(soc_camera_bus_type, cam_notifier);
2. in your notifier you verify, that the driver is already available, or
request_module(my-regulator-driver), and use another notifier to wait,
until the driver is probed.
3. if the above has been successful, in your .power() method you just use
the regulator as usual.
Notice, that your current patch doesn't load regulator driver modules, so,
it also relies on them being already available at the time of camera
probing. If you can live with that restriction, you can skip loading the
module and waiting for its probe above too.
The reasons why I do not want to add this to the core are: (1) I do not
want to have two methods for turning power on and off: a platform provided
.power() hook and and a set of regulators, (2) would anyone really want to
use several regulators for a camera sensor? If so, can it be the case,
that, for example, the regulators have to be switched off in the reverse
order to switching on? Or something else? (3) regulators can often do
more, than just set one of two power levels - for on and off. What if a
need arises to use other voltages?
Is there any really good reason, why we _have_ to do this in soc-camera
core?
Thanks
Guennadi
What the machine code have to do to use this functionality is to:
1- Define a number of useful regulator supply descriptions such as:
static struct regulator_consumer_supply camera_reg1_consumers[] = {
...
REGULATOR_SUPPLY(camera_reg1, soc-camera-pdrv.0),
...
};
(Pay attention at the .N suffix of soc-camera-pdrv in case of
a system with multiple cameras)
2- Define the list of regulators to bind to a specific instance of
soc-camera-pdrv with their voltages:
static struct soc_camera_regulator_desc soc_camera_regs[] = {
SOCAM_REG_DESC(camera_reg1, 130, 130),
SOCAM_REG_DESC(camera_reg2, 280, 280),
...
};
3- Add the list to the corresponding soc_camera_link description:
static struct soc_camera_link iclink_my_camera = {
...
.soc_regulator_descs= soc_camera_regs,
.num_soc_regulator_descs= ARRAY_SIZE(soc_camera_regs),
};
4- And register it as usual with the platform device description:
static struct platform_device machine_my_camera = {
.name = soc-camera-pdrv,
.id = 0,
.dev= {
.platform_data = iclink_my_camera,
},
};
Signed-off-by: Alberto Panizzo maramaopercheseimo...@gmail.com
---
drivers/media/video/soc_camera.c | 135 +++--
include/media/soc_camera.h | 16 +
2 files changed, 129 insertions(+), 22 deletions(-)
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c
index 43848a7..8fc5831 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -43,6 +43,96 @@ static LIST_HEAD(hosts);
static LIST_HEAD(devices);
static DEFINE_MUTEX(list_lock); /* Protects the list of hosts */
+static int soc_camera_setup_regulators(struct soc_camera_device *icd,
+ struct soc_camera_link *icl)
+{
+ int i, ret;
+
+ icd-soc_regulators = kzalloc(icl-num_soc_regulator_descs *
+ sizeof(struct regulator *), GFP_KERNEL);
+ if (!icd-soc_regulators) {
+ dev_err(icd-pdev, Not enough memory.\n);
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ for (i = 0; i icl-num_soc_regulator_descs; i++) {
+ dev_dbg(icd-pdev, Looking for reg:'%s' bound to dev:'%s',
+ icl-soc_regulator_descs[i].supply,
+ dev_name(icd-pdev));
+ icd-soc_regulators[i] = regulator_get(icd-pdev,
+ icl-soc_regulator_descs[i].supply);
+ if (IS_ERR(icd-soc_regulators[i])) {
+ icd-soc_regulators[i] = NULL;
+ dev_err(icd-pdev, Unable to get regulator: \%s\.\n,
+ icl-soc_regulator_descs[i].supply);
+ ret = -ENODEV;
+ goto free_regs;
+ }
+ }
+
+ icd-num_soc_regulators = icl-num_soc_regulator_descs;
+
+ return 0;
+
+free_regs:
+ for (i--; i = 0; i--)
+ regulator_put(icd-soc_regulators[i]);
+err:
+ return ret;
+}
+
where can I report dvb module related bug reports?
Hi, Sorry folks I know that dvb driver development is done in your spare time. However posting to this list or linux-dvb I got no answers which is really frustrating :-(. Please can you tell me which is the prefered way for submitting bug reports to dvb driver developers? Please can you help with the following things: http://www.mail-archive.com/linux-media@vger.kernel.org/msg12758.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg21646.html THX Regards halim -- 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: Disable IR on dvb_usb_af9015
Josu Lazkano wrote: Thanks for your reply. 2010/11/28 Antti Palosaari cr...@iki.fi: There is no module or per device basis option for that. Use option from module dvb-usb. Sorry, but I don't know how to use the option from module dvb-usb, I am new on this. I want to disable it, because I have problems to assign LIRC which input to choose. Kind regards. Antti On 11/28/2010 02:58 PM, Josu Lazkano wrote: Hello list! I have a Kworld U399U twin DVB-T adapter. It has a IR rceiver and I want to disable it from module on /etc/modprobe.d/options.conf Is any way to do this? I use to use the modprobe option to assign the number of the adapters: options dvb_usb_af9015 adapter_nr=4,5 It will be great to disable the IR. Thanks for all and best regards. -- http://palosaari.fi/ /etc/modprobe.d/options.conf: options dvb-usb disable_rc_polling=1 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
RFC: Problem of using v4l2 spec with codec function
Hello, everyone. When it comes to using v4l2 standard spec, I have a question about that. A month ago, Kamil Debski posted second version for the driver of a hw video codec. To be exact, it is decoding function of hw video codec which is called MFC(Multi Format Codec). For members not accustomed to this, refer to link as below. : http://www.spinics.net/lists/linux-media/msg24682.html I'm preparing for patch of encoding function of MFC. But simply I could say, According to the current version of v4l2 standard, User cannot call encoder or decoder differentially. I mean, Kamil designed MFC decoder driver using m2m style(not using by m2m framework, but V4L2_CAP_VIDEO_OUTPUT, V4L2_CAP_VIDEO_CAPTURE) And it would be almost same to implement encoder in terms of using same m2m style. But user should be able to call decoder for decoding, Due to the same reason, user should be able to call encoder. Of course, some different functions b/w encoder decoder are called. (Driver should know what function(enc or dec) is called) What do you think is the best way to let driver know what function user wants to execute ? 1. VIDIOC_QUERYCAP is mandatory, but it doesn't define about any encoder, decoder in the v4l2_capability : we need new capability for codec such as V4L2_BUF_TYPE_VIDEO_ENCODER, V4L2_BUF_TYPE_VIDEO_DECODER 2. What about using VIDIOC_S_CTRL, but it requires new defined decoder or encoder as a ctrl.id. Another problem is VIDIOC_S_CTRL is optional 3. What about VIDIOC_S_FMT ? it is also optional, which means default format will be used if not VIDIOC_S_FMT called. Let me know best way such as one among appropriate way that I mentioned as above, or any other idea ? Thanks all -- peter Oh, Senior Engineer SW Solution Development Team, System LSI Division, Samsung Electronics, Co., Ltd. Phone: +82-31-32-52287 Mobile:+82-10-3369-1989 Email: jaeryul...@samsung.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: problem af9015: tuner id:177 not supported, please report!
Antti Palosaari wrote: It is MxL5007T. Has gone to the 2.6.37. Antti On 11/28/2010 05:55 PM, helmut.neume...@gmx.de wrote: hello i have a prob lem with a tv-stick i get the error af9015: tuner id:177 not supported, please report! uname -r 2.6.32-25-generic-pae can anybody help me i have downloaded the actual source but i get the same error. Thanks to Mauro, at least people CAN try: == [ANNOUNCE] new experimental building system == ... If you want to test the new building system, all you need to do is: $ git clone git://linuxtv.org/mchehab/new_build.git $ cd new_build $ ./build.sh This will download the newest tarball from linuxtv.org, apply the backport patches and build it. After that, you may install the new drivers with: $ make install ... Referring to changes in 'new_build.git', /etc/modprobe.d/options.conf: # Disabling the remote control sensor options dvb-usb disable_rc_polling=1 # At Least For 'Not Only TV/LifeView DUAL DVB-T USB LV52T' options dvb-core dvb_powerdown_on_sleep=0 # EOF 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: where can I report dvb module related bug reports?
On Sun, Nov 28, 2010 at 5:06 PM, Halim Sahin halim.sa...@freenet.de wrote: Hi, Sorry folks I know that dvb driver development is done in your spare time. However posting to this list or linux-dvb I got no answers which is really frustrating :-(. Please can you tell me which is the prefered way for submitting bug reports to dvb driver developers? Hi I am not developer however been on this list since move. This is the appropriate list. However I search my archive(gmail account) and I didn't get them. I find it interesting that they are in the mail-archive archive. I would assume something may have happened with the mail server. Hopefully as this reply shows you will get your help. Later Jonathan Please can you help with the following things: http://www.mail-archive.com/linux-media@vger.kernel.org/msg12758.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg21646.html THX Regards halim -- 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 -- ASUS M4A78 PRO motherboard Athlon II X4 640 Processor 4 Gigabytes of DDR2-800 Gigabyte nVidia 9400gt Graphics adapter KWorld ATSC 110 TV Capture Card KWorld ATSC 115 TV Capture Card -- 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: RTL2832U-FC0012 AF9015-MXL5007T
poma wrote: RTL2832U-FC0012 AF9015-MXL5007T Setup for DVB-T devices, Realtek RTL2832U / Fitipower FC0012 Afatech AF9015 / MaxLinear MXL5007T dual tuner on Fedora 14-x86_64 with new experimental building system. lsusb: Bus 002 Device 002: ID 1f4d:b803 G-Tek Electronics Group Lifeview LV5TDLX DVB-T [RTL2832U] Bus 001 Device 002: ID 15a4:9016 Afatech Technologies, Inc. AF9015 DVB-T USB2.0 stick uname: 2.6.35.6-48.fc14.x86_64 modinfo: modinfo dvb_usb_rtl2832u: filename: /lib/modules/2.6.35.6-48.fc14.x86_64/kernel/drivers/media/dvb/dvb-usb/dvb-usb-rtl2832u.ko license:GPL version:2.0.1 description:Driver for the RTL2832U DVB-T / RTL2836 DTMB USB2.0 device author: Realtek srcversion: BABFD424CE8A0E806A95C01 alias: usb:v1554p5020d*dc*dsc*dp*ic*isc*ip* alias: usb:v1554p5013d*dc*dsc*dp*ic*isc*ip* alias: usb:v1F4DpD803d*dc*dsc*dp*ic*isc*ip* alias: usb:v1F4DpC803d*dc*dsc*dp*ic*isc*ip* alias: usb:v1F4DpB803d*dc*dsc*dp*ic*isc*ip* alias: usb:v1F4DpA803d*dc*dsc*dp*ic*isc*ip* alias: usb:v1D19p1104d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pD394d*dc*dsc*dp*ic*isc*ip* alias: usb:v0BDAp2837d*dc*dsc*dp*ic*isc*ip* alias: usb:v0BDAp2834d*dc*dsc*dp*ic*isc*ip* alias: usb:v0BDAp2839d*dc*dsc*dp*ic*isc*ip* alias: usb:v0BDAp2836d*dc*dsc*dp*ic*isc*ip* alias: usb:v1F4Dp0837d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pD398d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pD393d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pD397d*dc*dsc*dp*ic*isc*ip* alias: usb:v13D3p3282d*dc*dsc*dp*ic*isc*ip* alias: usb:v13D3p3234d*dc*dsc*dp*ic*isc*ip* alias: usb:v1164p6601d*dc*dsc*dp*ic*isc*ip* alias: usb:v1680pA332d*dc*dsc*dp*ic*isc*ip* alias: usb:v0BDAp2838d*dc*dsc*dp*ic*isc*ip* alias: usb:v1D19p1103d*dc*dsc*dp*ic*isc*ip* alias: usb:v1D19p1102d*dc*dsc*dp*ic*isc*ip* alias: usb:v1D19p1101d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pD396d*dc*dsc*dp*ic*isc*ip* alias: usb:v13D3p3274d*dc*dsc*dp*ic*isc*ip* alias: usb:v0BDAp2832d*dc*dsc*dp*ic*isc*ip* depends:dvb-usb vermagic: 2.6.35.6-48.fc14.x86_64 SMP mod_unload parm: debug:Set debugging level (1=info,xfer=2 (or-able)). (int) parm: demod:Set default demod type(0=dvb-t, 1=dtmb, 2=dvb-c) (int) parm: dtmb_err_discard:Set error packet discard type(0=not discard, 1=discard) (int) parm: adapter_nr:DVB adapter numbers (array of short) modinfo dvb_usb_af9015: filename: /lib/modules/2.6.35.6-48.fc14.x86_64/kernel/drivers/media/dvb/dvb-usb/dvb-usb-af9015.ko license:GPL description:Driver for Afatech AF9015 DVB-T author: Antti Palosaari cr...@iki.fi srcversion: 0F2842A63411F6AF9DD4B5B alias: usb:v1F4Dp9016d*dc*dsc*dp*ic*isc*ip* alias: usb:v07CAp850Bd*dc*dsc*dp*ic*isc*ip* alias: usb:v0CCDp0099d*dc*dsc*dp*ic*isc*ip* alias: usb:v0CCDp0097d*dc*dsc*dp*ic*isc*ip* alias: usb:v07CAp815Ad*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pE39Ad*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pE383d*dc*dsc*dp*ic*isc*ip* alias: usb:v0413p6A04d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pE402d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pE39Dd*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pC161d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pE400d*dc*dsc*dp*ic*isc*ip* alias: usb:v0458p4012d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pC810d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pE397d*dc*dsc*dp*ic*isc*ip* alias: usb:v07CApA805d*dc*dsc*dp*ic*isc*ip* alias: usb:v07CAp850Ad*dc*dsc*dp*ic*isc*ip* alias: usb:v15A4p901Bd*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pE395d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pE39Bd*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pE396d*dc*dsc*dp*ic*isc*ip* alias: usb:v1462p8807d*dc*dsc*dp*ic*isc*ip* alias: usb:v07CApA309d*dc*dsc*dp*ic*isc*ip* alias: usb:v10B9p8000d*dc*dsc*dp*ic*isc*ip* alias: usb:v07CAp8150d*dc*dsc*dp*ic*isc*ip* alias: usb:v1462p8801d*dc*dsc*dp*ic*isc*ip* alias: usb:v1AE7p0381d*dc*dsc*dp*ic*isc*ip* alias: usb:v07CApA815d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pC160d*dc*dsc*dp*ic*isc*ip* alias: usb:v0CCDp0069d*dc*dsc*dp*ic*isc*ip* alias: usb:v13D3p3237d*dc*dsc*dp*ic*isc*ip* alias: usb:v13D3p3226d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pE399d*dc*dsc*dp*ic*isc*ip* alias: usb:v2304p022Bd*dc*dsc*dp*ic*isc*ip* alias: usb:v0413p6029d*dc*dsc*dp*ic*isc*ip* alias: usb:v15A4p9016d*dc*dsc*dp*ic*isc*ip* alias: usb:v15A4p9015d*dc*dsc*dp*ic*isc*ip* depends:dvb-usb,i2c-core,ir-core vermagic: 2.6.35.6-48.fc14.x86_64 SMP mod_unload parm: debug:set debugging level (int) parm: remote:select
[GIT PATCHES for 2.6.38] broken cx25840 probe and CX2388[578] IR receive timeoouts
Mauro, Please pull the following changes for 2.6.38. The cx25840 module has a bad bug in its probe function which causes device probing to fail. It can completely break cx23885 IR and analog video and ivtv and pvrusb2 analog video. (Can you checrry pick the cx25840-core.c commit for 2.6.37 as well? commit 18688563aa635993cf31edc6a985a8a6736044f7 cx25840: Prevent device probe failure due to volume control ERANGE error) Regards, Andy The following changes since commit a287789447cecc7a82ffc4451cbaf16a5c1dccc0: [media] [FOR, 2.6.37] Revert V4L/DVB: v4l2-dev: remove unnecessary lock around atomic clear_bit (2010-11-26 18:41:02 -0200) are available in the git repository at: ssh://linuxtv.org/git/awalls/media_tree.git ir-38 Andy Walls (2): cx25840: Prevent device probe failure due to volume control ERANGE error cx23885, cx25840: Provide an IR Rx timeout event reports to the rc decoders drivers/media/video/cx23885/cx23888-ir.c | 12 drivers/media/video/cx25840/cx25840-core.c | 19 +-- drivers/media/video/cx25840/cx25840-ir.c | 12 3 files changed, 33 insertions(+), 10 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
RE: [PATCH 1/7] v4l: add videobuf2 Video for Linux 2 driver framework
Hello,
On Friday, November 26, 2010 7:00 PM Laurent Pinchart wrote:
On Friday 26 November 2010 17:49:02 Pawel Osciak wrote:
On Thu, Nov 25, 2010 at 01:48, Marek Szyprowski wrote:
Hello,
On Thursday, November 25, 2010 2:17 AM Laurent Pinchart wrote:
On Friday 19 November 2010 16:55:38 Marek Szyprowski wrote:
From: Pawel Osciak p.osc...@samsung.com
Videobuf2 is a Video for Linux 2 API-compatible driver framework for
[snip]
+/**
+ * vb2_mmap() - map video buffers into application address space
+ * @q: videobuf2 queue
+ * @vma: vma passed to the mmap file operation handler in the
driver + *
+ * Should be called from mmap file operation handler of a driver.
+ * This function maps one plane of one of the available video buffers
to + * userspace. To map whole video memory allocated on reqbufs,
this function + * has to be called once per each plane per each
buffer previously allocated. + *
+ * When the userspace application calls mmap, it passes to it an
offset returned + * to it earlier by the means of vidioc_querybuf
handler. That offset acts as + * a cookie, which is then used to
identify the plane to be mapped. + * This function finds a plane with
a matching offset and a mapping is performed + * by the means of a
provided memory operation. + *
+ * The return values from this function are intended to be directly
returned + * from the mmap handler in driver.
+ */
+int vb2_mmap(struct vb2_queue *q, struct vm_area_struct *vma)
+{
+ unsigned long off = vma-vm_pgoff PAGE_SHIFT;
+ struct vb2_plane *vb_plane;
+ struct vb2_buffer *vb;
+ unsigned int buffer, plane;
snip
+
+ vb = q-bufs[buffer];
+ vb_plane = vb-planes[plane];
+
+ if (vb_plane-mapped) {
+ dprintk(1, Plane already mapped\n);
What is the reason to disallow buffers from being mapped several times ?
If there's a valid one, it would be worth adding it in a comment here.
I see no reason, maybe Pawel will explain it a bit more. IMHO this check
can be removed.
First thing, I think we talked about that on IRC with Hans and agreed
that we don't really need to map a buffer multiple times from one
process. This is also carried over from vb1 as far as I can remember.
I think it was there because vb1 used to allocate memory on mmap, to
prevent multiple allocations. This check could be removed, but do we
really need such a feature?
What if a process calls fork() or pthread_create() with an existing mapping ?
I seem to remember that the mmap operation handler can be called again.
It was probably handled this way in some older kernels. Currently a vm_area is
just copied and a vm_open() op is called if provided.
I agree however that there is no real reason to limit number of mmap calls.
+ * @buf_alloc: called to allocate a struct vb2_buffer;
driver usually + * embeds it in its own custom buffer
structure; returns + * a pointer to vb2_buffer or
NULL if failed; if not + * provided
kmalloc(sizeof(struct vb2_buffer, GFP_KERNEL) + * is
used
+ * @buf_free: called to free the structure allocated by
@buf_alloc; + * if not provided kfree(vb) is used
I'm curious, do we have use cases for buf_alloc != kmalloc and buf_free
!= kfree ?
Well, the problem is not which function to call, but the size that is
passed as the argument. Drivers usually wants to embed the struct vb2
inside its own 'buffer' structure. See vivi driver ported to vb2 for the
reference. The driver get a pointer to vb2 and the uses containerof() to
get his own buffer. To make it possible the buffer need to be allocated
by the driver not the vb2. Currently I found no other way of solving
this than such callbacks.
I really didn't like how the concept of embedding structures
complicated both vb1 and is now complicating vb2. Maybe we should
think about going back to driver private structures and fixed-size
videobuf buffers?
I'm open to discussions on this :-)
2:1, as I will probably get back to the way it was handled in videobuf1 (with
the
requirement that struct vb2 must be a first element of driver's custom buffer).
+ * @buf_init: called once after allocating a buffer (in
MMAP case) + * or after acquiring a new USERPTR
buffer; drivers may + * perform additional
buffer-related initialization; + * initialization
failure (return != 0) will prevent + * queue setup
from completing successfully; optional + * @buf_prepare: called
every time the buffer is queued from userspace; + *
drivers may perform any initialization required before + *
each hardware operation in this callback; + *
Re: RFC: Problem of using v4l2 spec with codec function
On Monday, November 29, 2010 00:52:15 Jaeryul Oh wrote: Hello, everyone. When it comes to using v4l2 standard spec, I have a question about that. A month ago, Kamil Debski posted second version for the driver of a hw video codec. To be exact, it is decoding function of hw video codec which is called MFC(Multi Format Codec). For members not accustomed to this, refer to link as below. : http://www.spinics.net/lists/linux-media/msg24682.html I'm preparing for patch of encoding function of MFC. But simply I could say, According to the current version of v4l2 standard, User cannot call encoder or decoder differentially. I mean, Kamil designed MFC decoder driver using m2m style(not using by m2m framework, but V4L2_CAP_VIDEO_OUTPUT, V4L2_CAP_VIDEO_CAPTURE) And it would be almost same to implement encoder in terms of using same m2m style. But user should be able to call decoder for decoding, Due to the same reason, user should be able to call encoder. Of course, some different functions b/w encoder decoder are called. (Driver should know what function(enc or dec) is called) What do you think is the best way to let driver know what function user wants to execute ? 1. VIDIOC_QUERYCAP is mandatory, but it doesn't define about any encoder, decoder in the v4l2_capability : we need new capability for codec such as V4L2_BUF_TYPE_VIDEO_ENCODER, V4L2_BUF_TYPE_VIDEO_DECODER The upcoming media controller might be used to signal the capability. I'd be opposed to use a new buftype for this. Actually, I'm not sure if you really need this. 2. What about using VIDIOC_S_CTRL, but it requires new defined decoder or encoder as a ctrl.id. Another problem is VIDIOC_S_CTRL is optional Wouldn't you have separate video device nodes for the decoder and for the encoder? Or are they mutually exclusive? I.e., only one or the other can be running at a time? 3. What about VIDIOC_S_FMT ? it is also optional, which means default format will be used if not VIDIOC_S_FMT called. Let me know best way such as one among appropriate way that I mentioned as above, or any other idea ? I have to admit it's not entirely clear to me what your problem is exactly. I *think* that what you are saying is that your hardware can have just a single 'm2m' video instance and so you want to allow the user to switch between the possible m2m functions (video encoder or decoder) dynamically. Is that right? If so, then I think creating a so-called 'private' control for your hardware would be the best way to go. As an example of private controls search for the V4L2_CID_MPEG_CX2341X_BASE define in videodev2.h. Regards, Hans Thanks all -- peter Oh, Senior Engineer SW Solution Development Team, System LSI Division, Samsung Electronics, Co., Ltd. Phone: +82-31-32-52287 Mobile:+82-10-3369-1989 Email: jaeryul...@samsung.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 -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
tm6000 and IR
Hi I try add IR for our TV cards. After my some changes IR is working. But when I remove USB stick from USB port modules crashed with dmesg [ 133.881750] tm6000: New video device @ 480 Mbps (6000:dec0, ifnum 0) [ 133.881759] tm6000: Found Beholder Wander DVB-T/TV/FM USB2.0 [ 134.343012] Board version = 0x67980bf4 [ 134.484013] board=0x67980bf4 [ 134.575011] tm6000 #0: i2c eeprom 00: 42 59 54 45 12 01 00 02 00 00 00 40 00 60 c0 de byte...@.`.. [ 134.687012] tm6000 #0: i2c eeprom 10: 01 00 10 20 40 01 28 03 42 00 65 00 68 00 6f 00 ... @.(.B.e.h.o. [ 134.799014] tm6000 #0: i2c eeprom 20: 6c 00 64 00 65 00 72 00 20 00 49 00 6e 00 74 00 l.d.e.r. .I.n.t. [ 134.911012] tm6000 #0: i2c eeprom 30: 6c 00 2e 00 20 00 4c 00 74 00 64 00 2e 00 ff ff l... .L.t.d. [ 135.023013] tm6000 #0: i2c eeprom 40: 22 03 42 00 65 00 68 00 6f 00 6c 00 64 00 20 00 .B.e.h.o.l.d. . [ 135.135015] tm6000 #0: i2c eeprom 50: 54 00 56 00 20 00 57 00 61 00 6e 00 64 00 65 00 T.V. .W.a.n.d.e. [ 135.247014] tm6000 #0: i2c eeprom 60: 72 00 ff ff ff ff ff ff ff ff 1a 03 56 00 69 00 r...V.i. [ 135.359013] tm6000 #0: i2c eeprom 70: 64 00 65 00 6f 00 43 00 61 00 70 00 74 00 75 00 d.e.o.C.a.p.t.u. [ 135.471013] tm6000 #0: i2c eeprom 80: 72 00 65 00 ff ff ff ff ff ff ff ff ff ff ff ff r.e. [ 135.583010] tm6000 #0: i2c eeprom 90: ff ff ff ff 16 03 30 00 30 00 30 00 30 00 30 00 ..0.0.0.0.0. [ 135.695010] tm6000 #0: i2c eeprom a0: 30 00 32 00 30 00 34 00 31 00 ff ff ff ff ff ff 0.2.0.4.1... [ 135.807012] tm6000 #0: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 135.919011] tm6000 #0: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 136.031014] tm6000 #0: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 136.143010] tm6000 #0: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 136.255014] tm6000 #0: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 136.360015] [ 136.362337] tuner 7-0061: chip found @ 0xc2 (tm6000 #0) [ 136.421801] xc5000 7-0061: creating new instance [ 136.450015] xc5000: Successfully identified at address 0x61 [ 136.450019] xc5000: Firmware has not been loaded previously [ 136.450025] tuner 7-0061: Tuner frontend module has no way to set config [ 136.504012] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... [ 136.564545] xc5000: firmware read 12401 bytes. [ 136.564549] xc5000: firmware uploading... [ 143.241011] xc5000: firmware upload complete... [ 144.670093] Trident TVMaster TM5600/TM6000/TM6010 USB2 board (Load status: 0) [ 144.671201] tm6000: open called (dev=video0) [ 144.825125] usb 1-1: link qh0-00ff/f6762340 start 0 [1/0 us] [ 144.888012] Registered IR keymap rc-behold-columbus [ 144.888159] input: tm5600/60x0 IR (tm6000 #0) as /class/input/input5 [ 144.888217] rc0: tm5600/60x0 IR (tm6000 #0) as /class/rc/rc0 [ 145.044067] usbcore: registered new interface driver tm6000 [ 145.882658] tm6000: open called (dev=video0) [ 156.860296] hub 1-0:1.0: state 7 ports 8 chg evt 0002 [ 156.860310] ehci_hcd :00:1d.7: GetStatus port 1 status 001002 POWER sig=se0 CSC [ 156.860323] hub 1-0:1.0: port 1, status 0100, change 0001, 12 Mb/s [ 156.860328] usb 1-1: USB disconnect, address 2 [ 156.860332] usb 1-1: unregistering device [ 156.860336] usb 1-1: usb_disable_device nuking all URBs [ 156.860370] usb 1-1: unlink qh0-00ff/f6762340 start 0 [1/0 us] [ 156.860432] tm6000_ir_urb_received start [ 156.860435] not ready [ 156.860440] ehci_hcd :00:1d.7: shutdown urb f4900cc0 ep3in-intr [ 156.860446] usb 1-1: unregistering interface 1-1:1.0 [ 156.860492] tm6000: disconnecting tm6000 #0 [ 156.860494] befor if (!ir) [ 156.860495] befor ir_input_unregister(ir-input-input_dev); [ 156.862220] BUG: unable to handle kernel NULL pointer dereference at 00f0 [ 156.862223] IP: [f80370a9] ir_close+0x12/0x20 [ir_core] [ 156.862230] *pde = [ 156.862232] Oops: [#1] PREEMPT SMP [ 156.862235] last sysfs file: /sys/class/video4linux/video0/uevent [ 156.862238] Modules linked in: rc_behold_columbus xc5000 tuner tm6000(C) v4l2_common ir_lirc_codec videodev lirc_dev ir_sony_decoder v4l1_compat videobuf_vmalloc ir_jvc_decoder videobuf_core ir_rc6_decoder ir_rc5_decoder ir_nec_decoder ir_common ir_core ppdev lp ipv6 nls_utf8 ntfs dm_snapshot dm_mirror dm_region_hash dm_log dm_mod sha1_generic arc4 ecb ppp_mppe ppp_generic slhc loop nvidia(P) snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd i2c_i801 psmouse parport_pc processor soundcore tpm_tis parport rng_core i2c_core intel_agp tpm button pcspkr serio_raw snd_page_alloc agpgart tpm_bios evdev ext3 jbd mbcache sr_mod sd_mod
RE: [PATCH v2 0/6] davinci vpbe: display driver for DM644X
Hi Murali, On Sat, Nov 27, 2010 at 20:14:46, Muralidharan Karicheri wrote: Manjunath, Could you re-send the patch 1/6? I can't find it either at my inbox or mailing list. I received the 1/6 in my inbox and also see it on patchwork and gmane. https://patchwork.kernel.org/patch/353081/ http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/25692 Can you please check your spam folder just in case... Thanks, Sekhar -- 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
Unsafe to reinsert HVR-1850 kernel modules?
My HVR-1850 card occasionally jams, meaning it still tunes (according to gnutv), but no mpeg stream comes through. This heals on reboot, but I figured it should also heal on module reinsertion. However, when I remove the CX23885 module, along with the full set of DVB and related modules, and then reinsert them, I get this error when I attempt to open the stream -- zvbi-atsc-cc will for instance trigger it: kernel:do_IRQ: 5.82 No irq handler for vector (irq -1) If one card was initially jammed, now all the cards are jammed -- I'm testing five cards at once. A discussion at http://www.mail-archive.com/linux-media@vger.kernel.org/msg22375.html suggested adding the kernel parameter pci=nommconf, but when I do that the problem does not go away -- and I also got this (perhaps unrelated): cx25840 15-0044: likely a confused/unresponsive cx2388[578] A/V decoder found @ 0x88 (cx23885[4]) cx25840 15-0044: A method to reset it from the cx25840 driver software is not known at this time Is it currently not safe to remove and reinsert the kernel modules for the HVR-1850, or am I just seeing a quirk? Cheers, Dave -- 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
gnutv: What causes DVR overflow?
I'm seeing great results with gnutv on HVR-1850 cards, but each recording triggers the message DVR overflow What is this, and what are the typical causes? What can I do to prevent it from happening? Could it be related to slow hard drives? I'm assuming an overflow results in some degree of corruption of the stream that I write to file. Cheers, Dave -- 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
