Re: + firedtv-fix-regression-tuning-fails-due-to-bogus-error-return.patch added to -mm tree
a...@linux-foundation.org wrote: The patch titled firedtv: fix regression: tuning fails due to bogus error return has been added to the -mm tree. Mauro, this one (v4l-dvb patch 13240) as well as firedtv: length field corrupt in ca2host if length127 (v4l-dvb patch 13237) are 2.6.32-rc material. The ca2host fix is possibly also good for 2.6.x.y, but this is something which Henrik knows better than me. -- Stefan Richter -=-==--= =-== ---== http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] NOVA-TD exeriences?
2009/11/2 Soeren Moch soeren.m...@stud.uni-hannover.de: Hi. I would be happy to hear if anyone has tried both the NOVA-TD and the NOVA-T. The NOVA-T has always worked perfectly here but I would like to know if the -TD will do the job of two NOVA-T's. And there also seems to be a new version out with two small antenna connectors instead of the previous configuration. Anyone tried it? Does it come with an antenna adaptor cable? http://www.hauppauge.de/de/pics/novatdstick_top.jpg Thankful for any info. Well I've this usb stick with these two small connectors - and it runs just fine. Though I think there is some problem with suspend/resume recently (2.6.32-rc5) and it needs some inspection. But it works just fine for dual dvb-t viewing. And yes - it contains two small antennas with small connectors and one adapter for normal antenna - i.e. 1 antenna input goes to 2 small antenna connectors. zdenek, your nova-td stick works just fine for dual dvb-t viewing? I always had this problem: When one channel is streaming and the other channel is switched on, the stream of the already running channel gets broken. see also: http://www.mail-archive.com/linux-media@vger.kernel.org/msg06376.html Can you please test this case on your nova-td stick? I'll recheck in the evening whether there are no regression, but I've been able to get 3 dvb-t independent (different mux) TV streams (with the usage of the second stick Aver Hybrid Volar HX proprietary Aver driver) with 2.6.29/30 vanilla kernels played at the same time on my C2D T61. Zdenek -- 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 5/6] mx31moboard: camera support
Hi Guennadi, Valentin Longchamp wrote: Guennadi Liakhovetski wrote: 3. to support switching inputs, significant modifications to soc_camera.c would be required. I read Nate's argument before, that as long as clients can only be accessed one at a time, this should be presented by multiple inputs rather than multiple device nodes. Somebody else from the V4L folk has also confirmed this opinion. In principle I don't feel strongly either way. But currently soc-camera uses a one i2c client to one device node model, and I'm somewhat reluctant to change this before we're done with the v4l2-subdev conversion. Sure, one step at a time. So for now the switching is not possible with soc_camera. My problem is that both cameras have the same I2C address since they are the same. Would I need to declare 2 i2c_device with the same address (I'm not sure it would even work ...) used by two _client_ platform_devices or would I have to have the two platform devices pointing to the same i2c_device ? I've finally had time to test all this. My current problem with registering the two cameras is that they both have the same i2c address, and soc_camera calls v4l2_i2c_new_subdev_board where in my case the same address on the same i2c tries to be registered and of course fails. We would need a way in soc_camera not to register a new i2c client for device but use an existing one (but that's what you don't want to change for now as you state it in your above last sentence). I just want to point this out once more so that you know there is interest about this for the next soc_camera works. So my current solution for mainline inclusion is to register only one camera device node without taking care of the cam mux for now. Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEA3485, Station 9, CH-1015 Lausanne -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Struggling with Astra 2D (Freesat) / Happauage Nova-HD-S2
I forgot to mention that you should use the transponders lists - ini file (for scan-s2) and xml file (for dvb2010) from here http://www.vdr-settings.com/download/channels/CLyngsatSP.tar.bz2 Goga you have to use scan-s2 http://mercurial.intuxication.org/hg/scan-s2 Hi, and thanks for your quick reply. I tried it but no better: snip initial transponder DVB-S 12692000 V 19532000 1/2 AUTO AUTO initial transponder DVB-S2 12692000 V 19532000 1/2 AUTO AUTO -- Using DVB-S tune to: 11720:hC34S0:S0.0W:29500: DVB-S IF freq is 112 WARNING: tuning failed!!! tune to: 11720:hC34S0:S0.0W:29500: (tuning failed) and the channels.conf was no better than before - it didn't include *one* BBC channel, for example. or dvb2010 scan http://hg.kewl.org/dvb2010/ Once I got it working, same: Astra 2A/2B/2D/Eurobird 1 (28.2E) 10714 H DVB-S QPSK 22000 5/6 ONID:0 TID:0 AGC:0% SNR:0% Can't tune Astra 2A/2B/2D/Eurobird 1 (28.2E) 10729 V DVB-S QPSK 22000 5/6 ONID:0 TID:0 AGC:0% SNR:0% Can't tune -- 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: pxa_camera + mt9m1111: image shifted (was: Failed to configure for format 50323234)
On Mon, 05 Oct 2009 08:32:10 +0200 Stefan Herbrechtsmeier hbme...@hni.uni-paderborn.de wrote: Antonio Ospite schrieb: On Sun, 4 Oct 2009 00:31:24 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Anyways your patch works, but the picture is now shifted, see: http://people.openezx.org/ao2/a780-pxa-camera-mt9m111-shifted.jpg Is this because of the new cropping code? Hm, it shouldn't be. Does it look always like this - reproducible? What program are you using? What about other geometry configurations? Have you ever seen this with previous kernel versions? New cropping - neither mplayer nor gstreamer use cropping normally. This seems more like a HSYNC problem to me. Double-check platform data? Is it mioa701 or some custom board? Platform data: if I set SOCAM_HSYNC_ACTIVE_HIGH the result is even wronger, with or without SOCAM_HSYNC_ACTIVE_LOW I get the same result, now reproducible, see below. Only for your information. Maybe it helps to reproduce the error. I have the same problem with my own ov9655 driver on a pxa platform since I update to kernel 2.6.30 and add crop support. Every first open of the camera after system reset the image looks like yours. If I use the camera the next time without changing the resolution everything is OK. Only during the first open the resolution of the camera is changed and function fmt set in the ov9655 driver is called twice. I use the camera with my one program and it doesn't use crop. Thanks Stefan, now I can reproduce the problem. 1. Boot the system 2. Capture an image with capture-example from v4l2-apps. Then I have the shift as in the picture above on the *first* device open, if I open the device again and capture a second time, without rebooting, the picture is fine. I'll let you know if I find more clues of what is causing this behavior. Thanks, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? pgp5LlBDIyRnT.pgp Description: PGP signature
Trying to compile for kernel version 2.6.28
At this moment, I cannot figure out how to compile v4l with kernel version 2.6.28. I see, however, that the daily build reports: linux-2.6.28-i686: OK I have the same problem as in the old message: http://www.spinics.net/lists/linux-media/msg10047.html I have included the text of that message below. How do I revert the latest changepatch to videobuf-dma-config ? And could somebody preferably put a kernel-version-dependent #if around that changepatch ? --- / / / Then I made it here:/ / / / CC [M] /home/mythbox/Firmware/v4l-dvb/v4l/videobuf-core.o/ / CC [M] /home/mythbox/Firmware/v4l-dvb/v4l/videobuf-dma-sg.o/ / CC [M] /home/mythbox/Firmware/v4l-dvb/v4l/videobuf-dma-contig.o/ / /home/mythbox/Firmware/v4l-dvb/v4l/videobuf-dma-contig.c: In function/ / 'videobuf_dma_contig_user_get':/ / /home/mythbox/Firmware/v4l-dvb/v4l/videobuf-dma-contig.c:164: error:/ / implicit declaration of function 'follow_pfn'/ / make[3]: *** [/home/mythbox/Firmware/v4l-dvb/v4l/videobuf-dma-contig.o] Error 1/ / make[2]: *** [_module_/home/mythbox/Firmware/v4l-dvb/v4l] Error 2/ / make[2]: Leaving directory `/usr/src/linux-headers-2.6.28-15-generic'/ / make[1]: *** [default] Error 2/ / make[1]: Leaving directory `/home/mythbox/Firmware/v4l-dvb/v4l'/ / make: *** [all] Error 2/ / / / Its kinda annoying that a year ago this was super easy.../ / / / I dont really want to bump up to 2.6.31 seeing it just came out a few days ago./ Ok, this is the usual backport issues we have every time we need to backport patches upstream. This should be solved soon, but currently my priority is to merge the pending patches at the tree. Up to then, you may do a: make menuconfig and select only the drivers you need, or just revert the latest changepatch to videobuf-dma-config. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: YUV frame alignment improvements
On Sun, Nov 1, 2009 at 6:15 PM, Andy Walls awa...@radix.net wrote: On Sun, 2009-11-01 at 17:59 -0500, Andy Walls wrote: On Sun, 2009-11-01 at 13:10 -0500, Brandon Jenkins wrote: Hi Andy, The panic happens upon reboot and it is only 1 line of text oddly shifted. Kernel panic - not syncing: DMA: Memory would be corrupted If I switch back to the current v4l-dvb drivers no issue. To switch back I have to boot from a USB drive. Brandon, Eww. OK. Nevermind performing any more data collection. I'm going to use a new strategy (when I find the time). I forgot to mention that the panic you are running into is in the Software IO Memory Managment Unit Translate Look-aside Buffer (SW IOMMU TLB) in linux/lib/swiotlb.c Your machine must not have a hardware IO MMU (and mine must). The software IOMMU is trying to allocate a bounce buffer for DMA and it can't get one of the needed size (i.e. 607.5 kB) and the fallback static buffer isn't big enough either (it is only 32 kB). That's why the panic happens. This certainly means that, in the general linux user case, very large DMA buffers are bad. So now I know Regards, Andy Hi Andy, How would I know if I have/don't have a HW IO MMU and maybe isn't enabled correctly? Separately, I also have three cards running too. Brandon -- 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 compiling libv4l 0.6.3
Hi, On 11/02/2009 05:23 PM, Pierre wrote: Hans de Goede wrote: Hi, On 10/28/2009 06:43 PM, Pierre wrote: # make make -C libv4lconvert V4L2_LIB_VERSION=0.6.3 all make[1]: Entering directory `/tmp/libv4l-0.6.3/libv4lconvert' gcc -Wp,-MMD,libv4lconvert.d,-MQ,libv4lconvert.o,-MP -c -I../include -I../../../include -fvisibility=hidden -fPIC -DLIBDIR=\/usr/local/lib\ -DLIBSUBDIR=\libv4l\ -g -O1 -Wall -Wno-unused -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -o libv4lconvert.o libv4lconvert.c cc1: error: unrecognized command line option -fvisibility=hidden make[1]: *** [libv4lconvert.o] Error 1 make[1]: Leaving directory `/tmp/libv4l-0.6.3/libv4lconvert' make: *** [all] Error 2 It would seem that you are using a very very old gcc. # gcc --version gcc (GCC) 3.4.3 Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. What is the version you recommend ? [h...@localhost ~]$ gcc --version gcc (GCC) 4.4.2 20091027 (Red Hat 4.4.2-7) Is what I use but any 4.x which supports -fvisibility=hidden should work fine. Note that you will probably also need newer kernel headers. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] NOVA-TD exeriences?
2009/11/3 Zdenek Kabelac zdenek.kabe...@gmail.com: 2009/11/2 Soeren Moch soeren.m...@stud.uni-hannover.de: Hi. I would be happy to hear if anyone has tried both the NOVA-TD and the NOVA-T. The NOVA-T has always worked perfectly here but I would like to know if the -TD will do the job of two NOVA-T's. And there also seems to be a new version out with two small antenna connectors instead of the previous configuration. Anyone tried it? Does it come with an antenna adaptor cable? http://www.hauppauge.de/de/pics/novatdstick_top.jpg Thankful for any info. Well I've this usb stick with these two small connectors - and it runs just fine. Though I think there is some problem with suspend/resume recently (2.6.32-rc5) and it needs some inspection. But it works just fine for dual dvb-t viewing. And yes - it contains two small antennas with small connectors and one adapter for normal antenna - i.e. 1 antenna input goes to 2 small antenna connectors. zdenek, your nova-td stick works just fine for dual dvb-t viewing? I always had this problem: When one channel is streaming and the other channel is switched on, the stream of the already running channel gets broken. see also: http://www.mail-archive.com/linux-media@vger.kernel.org/msg06376.html Can you please test this case on your nova-td stick? I'll recheck in the evening whether there are no regression, but I've been able to get 3 dvb-t independent (different mux) TV streams (with the usage of the second stick Aver Hybrid Volar HX proprietary Aver driver) with 2.6.29/30 vanilla kernels played at the same time on my C2D T61. Ok - I could confirm, I'm able to play two different muxes at the same time from this USB stick. And I do not experience any stream damage. I'm running Fedora Rawhide with vanilla kernel 2.6.32-rc5, kaffeine 0.8.7 for the first adapter and relatively fresh mplayer compilation for the second adapter Thought there are things to be reported and fixed (some USB regression I guess) - I'll handle this via lkml. Anyway here is dmesg USB stick identification (labeled WinTV Nova-TD) USB device found, idVendor=2040, idProduct=5200 USB device strings: Mfr=1, Product=2, SerialNumber=3 Product: NovaT 500Stick Regards Zdenek -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Struggling with Astra 2D (Freesat) / Happauage Nova-HD-S2
TD wrote: I tried it but no better: snip initial transponder DVB-S 12692000 V 19532000 1/2 AUTO AUTO initial transponder DVB-S2 12692000 V 19532000 1/2 AUTO AUTO see if this channels.conf file is of any use to you i'm sure it is horribly out of date but i know that the BBC services work i do use them with myth -- simon channels.conf.gz Description: application/gzip
Re: cx18: YUV frame alignment improvements
On Tue, 2009-11-03 at 12:06 -0500, Brandon Jenkins wrote: On Sun, Nov 1, 2009 at 6:15 PM, Andy Walls awa...@radix.net wrote: On Sun, 2009-11-01 at 17:59 -0500, Andy Walls wrote: On Sun, 2009-11-01 at 13:10 -0500, Brandon Jenkins wrote: Hi Andy, The panic happens upon reboot and it is only 1 line of text oddly shifted. Kernel panic - not syncing: DMA: Memory would be corrupted If I switch back to the current v4l-dvb drivers no issue. To switch back I have to boot from a USB drive. Brandon, Eww. OK. Nevermind performing any more data collection. I'm going to use a new strategy (when I find the time). I forgot to mention that the panic you are running into is in the Software IO Memory Managment Unit Translate Look-aside Buffer (SW IOMMU TLB) in linux/lib/swiotlb.c Your machine must not have a hardware IO MMU (and mine must). The software IOMMU is trying to allocate a bounce buffer for DMA and it can't get one of the needed size (i.e. 607.5 kB) and the fallback static buffer isn't big enough either (it is only 32 kB). That's why the panic happens. This certainly means that, in the general linux user case, very large DMA buffers are bad. So now I know Regards, Andy Hi Andy, How would I know if I have/don't have a HW IO MMU and maybe isn't enabled correctly? There's no simple way AFAICT, except for believing that kernel couldn't find one. You'll have to research your motherboard's chipset and determine if the chipset has one. Chip vendors have IOMMU's as part of larger specifications: http://en.wikipedia.org/wiki/IOMMU Linux has some detection code on startup for IOMMU's it knows about, provided you've configured the IOMMU support in the kernel. Check your kernel config I guess. Also check your BIOS for anymention of an IOMMU there. Separately, I also have three cards running too. 3 times as many buffer allocations would exacerbate the ability to find large contiguous memory buffers in PCI device DMA-able memory. The CX23418 firmware is smart enough to use scatter gather type lists of buffers (called MDLs by the firmware); I just need to fix the cx18 driver to use them as such. Regards, Andy Brandon -- 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] isl6421.c - added optional features: tone control and temporary diseqc overcurrent
Hi Honza, Am Mittwoch, den 04.11.2009, 00:10 +0100 schrieb HoP: Hi Mauro, thank you for your valued hints. I'm commenting inside message: First of all, please check all your patches with checkpatch, to be sure that they don't have any CodingStyle troubles. There are some on your patch (the better is to read README.patches for more info useful for developers). Did checkpatch testing and has fixed all errors/warnings except of 3 warning regarding longer line (all 3 lines has exactly one char over 80, so I guess it should not bother much). Of course if this rule is a must, then I can fix that also). Attached patch adds two optional (so, disabled by default and therefore could not break any compatibility) features: 1, tone_control=1 When enabled, ISL6421 overrides frontend's tone control function (fe-ops.set_tone) by its own one. On your comments, the better is to describe why someone would need to use such option. You should also add a quick hint about that at the option description. Well, I'm not sure I can make some good hint why such option can be useful by someone. I can only say that isl6121 has possibility to drive 22k tone, so why not enable usage of it? well, we have much more experienced guys than me here on that, but it should be device specific then. Of course, we made such code because we were using exactly this way of 22k control in our device. So the demod can't do it or just free choice? 2, overcurrent_enable=1 When enabled, overcurrent protection is disabled during sending diseqc command. Such option is usable when ISL6421 catch overcurrent threshold and starts limiting output. Note: protection is disabled only during sending of diseqc command, until next set_tone() usage. What typically means only max up to few hundreds of ms. WARNING: overcurrent_enable=1 is dangerous and can damage your device. Use with care and only if you really know what you do. I'm not sure if it is a good idea to have this... Why/when someone would need this? I know that it is a bit dangerous option, so I can understand you can don't like it :) But I would like to note again - such way of using is permitted by datasheet (otherwise it would not be even possible to enable it) and we learnt when used correctly (it is enabled only within diseqc sequence), it boost rotor moving or fixes using some power-eating diseqc switches. If you still feel it is better to not support bit strange mode, then I can live with #if 0 commented out blocks or adding some kernel config option with something like ISL6421_ENABLE_OVERCURRENT or so. Question is, can you melt down some chip with it or not? If you can, stay away, since this was not in the scope earlier. Cheers, Hermann If we go ahead and add this one, you should add a notice about it at the parameter. I would also print a big WARNING message at the dmesg if the module were loaded with this option turned on. Added some WARNING printing to dmesg when option is enabled. Regards /Honza --- Signed-off-by: Jan Petrous jpetr...@gmail.com Signed-off-by: Ales Jurik aju...@quick.cz -- 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] isl6421.c - added optional features: tone control and temporary diseqc overcurrent
Hi Mauro,
thank you for your valued hints. I'm commenting inside
message:
First of all, please check all your patches with checkpatch, to be sure
that they don't have any CodingStyle troubles. There are some on your
patch (the better is to read README.patches for more info useful
for developers).
Did checkpatch testing and has fixed all errors/warnings except
of 3 warning regarding longer line (all 3 lines has exactly
one char over 80, so I guess it should not bother much).
Of course if this rule is a must, then I can fix that also).
Attached patch adds two optional (so, disabled by default
and therefore could not break any compatibility) features:
1, tone_control=1
When enabled, ISL6421 overrides frontend's tone control
function (fe-ops.set_tone) by its own one.
On your comments, the better is to describe why someone would need
to use such option. You should also add a quick hint about that at the
option description.
Well, I'm not sure I can make some good hint why such option can
be useful by someone. I can only say that isl6121 has possibility
to drive 22k tone, so why not enable usage of it?
Of course, we made such code because we were using exactly
this way of 22k control in our device.
2, overcurrent_enable=1
When enabled, overcurrent protection is disabled during
sending diseqc command. Such option is usable when ISL6421
catch overcurrent threshold and starts limiting output.
Note: protection is disabled only during sending
of diseqc command, until next set_tone() usage.
What typically means only max up to few hundreds of ms.
WARNING: overcurrent_enable=1 is dangerous
and can damage your device. Use with care
and only if you really know what you do.
I'm not sure if it is a good idea to have this... Why/when someone would
need this?
I know that it is a bit dangerous option, so I can understand you can
don't like it :)
But I would like to note again - such way of using is permitted
by datasheet (otherwise it would not be even possible to enable it)
and we learnt when used correctly (it is enabled only within diseqc
sequence), it boost rotor moving or fixes using some power-eating
diseqc switches.
If you still feel it is better to not support bit strange mode, then
I can live with #if 0 commented out blocks or adding some
kernel config option with something like ISL6421_ENABLE_OVERCURRENT
or so.
If we go ahead and add this one, you should add a notice about it at the
parameter.
I would also print a big WARNING message at the dmesg if the module were
loaded
with this option turned on.
Added some WARNING printing to dmesg when option is enabled.
Regards
/Honza
---
Signed-off-by: Jan Petrous jpetr...@gmail.com
Signed-off-by: Ales Jurik aju...@quick.cz
diff -r 9d9bc92d7c33 drivers/media/dvb/frontends/isl6421.c
--- a/drivers/media/dvb/frontends/isl6421.c Sat Sep 19 12:48:44 2009 +0200
+++ b/drivers/media/dvb/frontends/isl6421.c Tue Nov 03 23:23:05 2009 +0100
@@ -3,6 +3,9 @@
*
* Copyright (C) 2006 Andrew de Quincey
* Copyright (C) 2006 Oliver Endriss
+ * Copyright (C) 2009 Ales Jurik and Jan Petrous (added optional 22k tone
+ *support and temporary diseqc overcurrent enable until
+ *next command - set voltage or tone)
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -35,12 +38,23 @@
#include dvb_frontend.h
#include isl6421.h
+static int tone_control;
+module_param(tone_control, int, S_IRUGO);
+MODULE_PARM_DESC(tone_control, Set ISL6421 to control 22kHz tone);
+
+static int overcurrent_enable;
+module_param(overcurrent_enable, int, S_IRUGO);
+MODULE_PARM_DESC(overcurrent_enable, Set ISL6421 to temporary enable
+ overcurrent when diseqc command is active);
+
struct isl6421 {
u8 config;
u8 override_or;
u8 override_and;
struct i2c_adapter *i2c;
u8 i2c_addr;
+ int (*diseqc_send_master_cmd_orig)(struct dvb_frontend *fe,
+ struct dvb_diseqc_master_cmd *cmd);
};
static int isl6421_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t voltage)
@@ -60,6 +74,55 @@ static int isl6421_set_voltage(struct dv
break;
case SEC_VOLTAGE_18:
isl6421-config |= (ISL6421_EN1 | ISL6421_VSEL1);
+ break;
+ default:
+ return -EINVAL;
+ };
+
+ isl6421-config |= isl6421-override_or;
+ isl6421-config = isl6421-override_and;
+
+ return (i2c_transfer(isl6421-i2c, msg, 1) == 1) ? 0 : -EIO;
+}
+
+static int isl6421_send_diseqc(struct dvb_frontend *fe,
+struct dvb_diseqc_master_cmd *cmd)
+{
+ struct isl6421 *isl6421 = (struct isl6421 *) fe-sec_priv;
+ struct i2c_msg msg = { .addr = isl6421-i2c_addr, .flags = 0,
+.buf = isl6421-config,
+.len = sizeof(isl6421-config) };
+
+ isl6421-config |= ISL6421_DCL;
+
+ isl6421-config |= isl6421-override_or;
+ isl6421-config = isl6421-override_and;
+
+ if (i2c_transfer(isl6421-i2c, msg, 1) != 1)
+ return -EIO;
+
+ isl6421-config = ~ISL6421_DCL;
+
+ return
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Nov 3 19:00:06 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13272:a8e1140e4c9a gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: WARNINGS linux-2.6.23.12-armv5: WARNINGS linux-2.6.24.7-armv5: WARNINGS linux-2.6.25.11-armv5: WARNINGS linux-2.6.26-armv5: WARNINGS linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-rc3-armv5: ERRORS linux-2.6.32-rc3-armv5-davinci: ERRORS linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-rc3-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: ERRORS linux-2.6.32-rc3-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-rc3-i686: ERRORS linux-2.6.23.12-m32r: WARNINGS linux-2.6.24.7-m32r: WARNINGS linux-2.6.25.11-m32r: WARNINGS linux-2.6.26-m32r: WARNINGS linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-rc3-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-rc3-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-rc3-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-rc3-x86_64: ERRORS sparse (linux-2.6.31): OK sparse (linux-2.6.32-rc3): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Struggling with Astra 2D (Freesat) / Happauage Nova-HD-S2
On Wed, 4 Nov 2009, TD wrote: removed linux-dvb x-post Oooh, that's a mistake (from my view) -- it means your reply doesn't appear in my inbox, and it's only through luck that I find it amongst the uninteresting (to me) posts that I check infrequently on linux-media via gmane -- I thought there was to be a separation between developer mail, and dvb-user mail, and this clearly falls into the latter. And is more my bag. But that's a rant I don't want to get into, as I'm in the minority here. Therefore the failure to tune DVB-S2 transponders has nothing to do with reception of Freesat. I wasn't aware - I thought the Freesat HD channels were DVB-S2, that's why I got that card. Now upon further research, it appears that talk of DVB-S2 with Freesat has died down, so looks like I've wasted some money (for now). Happy to offer the background. I wouldn't say you've wasted money -- rather, you've future-proofed yourself. Sadly the Freesat specs don't appear to have mandated the more efficient H.264 AVC video codec for SD resolution services, so there is no possibility of that for a Freesat-only (no BSkyB) service that wants to save transmission costs, yet still be received by the handful of non-HD-able receivers out there. I'd liken it to my decision not to buy any DAB-only receiver without the DAB+ (and DMB) capability that is presently in use (if not in the UK or other countries), or any further DVB-S cards without -S2. And DVB-T2. What seems like a waste of money today will guarantee you don't have to spend as much later -- with your DVB-S2 card and a suitably positioned dish, you could be receiving the french-german `arte' where occasional programmes capture my interest, as well as other FTA services that have not yet interested me in a pure -S2 form. Also, while the Beeb may not presently be transmitting -S2 for their HD service, I wouldn't rule it out. There's a long and sordid history behind Freesat and the Continent that limits what is available via Freesat and its quality to what the 2D satellite can deliver, and any future services (such as the recent Freesat `Five') will need to be shoehorned into that already overfilled space. My channels.conf contains both horizontal and vertical channels, but nothing below 11700. So it looks like I'm not getting anything via low band? Thanks for confirming this. This points to a potential, but unlikely, problem with your device, that it can't switch into the low band (I had a problem where one of my devices could not receive anything in the high band without hackery, or a multiswitch which spoke to it differently). If you are not aware of it, in case it helps, the switching between low (below 11700-ish) and high band is normally accomplished with a 22kHz tone signal, absent for low band. It can also be accomplished by a particular DiSEqC signal which my one device speaks to the multiswitch I got which solved that problem, that being the opposite to what you are experiencing. The other possibility, given that two of the four inputs to your multiswitch work, is that the two low-band inputs have been crossed. If you have a complete lack of any results with one particular polarisation/band combination, then suspect possibly your cabling, unless a regular FTA/Freesat/Sky receiver connected to the same is able to successfully find all services. As per my OP: = The setup is that this is a newly-built flat, with a double F-socket on the = wall. I followed it down to the distribution panel in the basement, and it's = connected to a Delta MS 5024 N multiswitch. From what I could make out, said = switch has four cables going in (vertical 0khz, horiz 0khz, vertical 22khz, = horiz 0khz), and lots of cables going to the flats. Surely it must be the switch, I don't see what else it can be, especially if there is no special signal that a Sky box sends down the wire to the switch, that my setup would need to replicate. Yeah, a third possibility could be the switch. I glossed over the details in your original post about the switch, and completely forgot it was newly-built. While I would normally expect everything to work in a new installation, I've read enough to convince me otherwise. As a confession, when I have to replace the cabling into my multiswitch, these days I determine the proper wiring by a process of elimination as to which of the four cables goes where. I recently had to do this with my dish pointed at 28,2/28,5°E and I'm always wary when I have the mathematically improbable result of the randomly selected cables being connected to the right inputs. But enough of my confessions why you wouldn't hire me to install anything you care about. There is a caveat above, which is that we are the first people in the block, so who knows what reception others are getting. I've already had the cables from the switch to our flat moved to a different switch, as when I mentioned Different switch, or different
Re: [PATCH 3/3] gspca pac7302/pac7311: separate the two subdrivers
Dear Jef, although I tested my patch on my development computer together with Labtec Webcam 2200 (gspca_pac7302 driver) it seems that the patch may cause regression on some computers. For example I tested the gspca_pac7302 driver from http://linuxtv.org/hg/~jfrancois/gspca/ on top of Linux kernel 2.6.32-rc5 on an EeePC 901. I get the following error message in dmesg: [ 4476.992201] usb 3-2: new full speed USB device using uhci_hcd and address 11 [ 4477.230485] usb 3-2: New USB device found, idVendor=093a, idProduct=2626 [ 4477.230507] usb 3-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 4477.231139] usb 3-2: configuration #1 chosen from 1 choice [ 4477.417456] Linux video capture interface: v2.00 [ 4477.437131] gspca: main v2.7.0 registered [ 4477.443214] gspca: probing 093a:2626 [ 4477.453491] gspca: /dev/video0 created [ 4477.453541] gspca: probing 093a:2626 [ 4477.453549] gspca: intf != 0 [ 4477.453598] gspca: probing 093a:2626 [ 4477.453605] gspca: intf != 0 [ 4477.453755] usbcore: registered new interface driver pac7302 [ 4477.453771] pac7302: registered [ 4489.552153] gspca: set alt 8 err -71 I bisected the problem on EeePC 901 and the changeset 13373:99c23949b411 (gspca - pac7302/pac7311: Separate the two subdrivers.) was marked as the first bad commit. On my development computer the same configuration works correctly: [ 7872.020222] usb 3-1: new full speed USB device using uhci_hcd and address 4 [ 7872.251240] usb 3-1: configuration #1 chosen from 1 choice [ 7872.744755] Linux video capture interface: v2.00 [ 7872.785032] gspca: main v2.7.0 registered [ 7872.797061] gspca: probing 093a:2626 [ 7872.807577] gspca: /dev/video0 created [ 7872.809747] usbcore: registered new interface driver pac7302 [ 7872.809798] pac7302: registered Is the separated driver working for you? Do you have any idea what could went wrong? Maybe some timing problem? Regards, Márton Németh Németh Márton wrote: From: Márton Németh nm...@freemail.hu All PAC7311 specific functions remain in pac7311.c. All PAC7302 specific functions are moved to pac7302.c. The USB device table is also divided into two parts. This makes it possible to remove the sensor specific decisions from different functions and also remove sensor infromation from the USB device table. The common functions are just copied to both subdrivers. These common functions can be separated later to a common file or helper module. Signed-off-by: Márton Németh nm...@freemail.hu Cc: Thomas Kaiser tho...@kaiser-linux.li Cc: Theodore Kilgore kilg...@auburn.edu Cc: Kyle Guinn ely...@gmail.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: [PATCH] isl6421.c - added optional features: tone control and temporary diseqc overcurrent
Hi Hermann, Attached patch adds two optional (so, disabled by default and therefore could not break any compatibility) features: 1, tone_control=1 When enabled, ISL6421 overrides frontend's tone control function (fe-ops.set_tone) by its own one. On your comments, the better is to describe why someone would need to use such option. You should also add a quick hint about that at the option description. Well, I'm not sure I can make some good hint why such option can be useful by someone. I can only say that isl6121 has possibility to drive 22k tone, so why not enable usage of it? well, we have much more experienced guys than me here on that, but it should be device specific then. Of course, we made such code because we were using exactly this way of 22k control in our device. So the demod can't do it or just free choice? Well, more detailed Ales can speak about it, he is hw guy here :) Anyway, regardless reason of choice important is that isl6421 can be used this way and, may be even more important, it is used (and works correctly) in our hardware. I understand it can be a bit non-usual way of usage, but as I said, it works for us :) 2, overcurrent_enable=1 When enabled, overcurrent protection is disabled during sending diseqc command. Such option is usable when ISL6421 catch overcurrent threshold and starts limiting output. Note: protection is disabled only during sending of diseqc command, until next set_tone() usage. What typically means only max up to few hundreds of ms. WARNING: overcurrent_enable=1 is dangerous and can damage your device. Use with care and only if you really know what you do. I'm not sure if it is a good idea to have this... Why/when someone would need this? I know that it is a bit dangerous option, so I can understand you can don't like it :) But I would like to note again - such way of using is permitted by datasheet (otherwise it would not be even possible to enable it) and we learnt when used correctly (it is enabled only within diseqc sequence), it boost rotor moving or fixes using some power-eating diseqc switches. If you still feel it is better to not support bit strange mode, then I can live with #if 0 commented out blocks or adding some kernel config option with something like ISL6421_ENABLE_OVERCURRENT or so. Question is, can you melt down some chip with it or not? If you can, stay away, since this was not in the scope earlier. We have tested it with few devices (both rotor and diseqc switches) and have not ran in any damage yet. TBH, I'm writing about possibility of damage only because of understanding that if I disable overcurrent safeguard I can imagine it can end up bad way. But not tested on our side. Regards /Honza -- 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: Trying to compile for kernel version 2.6.28
Hi Jan, Em Tue, 03 Nov 2009 16:45:15 +0100 Jan Hoogenraad jan-conceptro...@hoogenraad.net escreveu: At this moment, I cannot figure out how to compile v4l with kernel version 2.6.28. I see, however, that the daily build reports: linux-2.6.28-i686: OK Yes, and that's correct. It does compile from scratch with 2.6.28. If you look at v4l/versions.txt, this is already marked to compile only with kernels 2.6.31 or newer. It should be noticed, however, that the building system won't touch at your .config if you just do an hg update (or hg pull -u). You'll need to ask it explicitly to process versions.txt again, by calling one of the alternatives bellow that re-generates a v4l/.config. If you are using a customized config, you'll need to call either one of those: make menuconfig make config make xconfig or make gconfig (in this specific case, just entering there and saving the config is enough - there's no need to touch on any items) Or, at the simple case were you're just building everything, you'll need to do: make allmodconfig A side effect of touching at v4l/.config is that all (selected) drivers will recompile again. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
