[linux-dvb] Re: Nova-T 500 (dvb_usb_dib0700) usb disconnects
Antti P Miettinen <[EMAIL PROTECTED]> writes: > The transaction error is for EP 3, we manage to schedule the halt > clear but the hard failure happens for EP 0. Hmm.. where are the > control urbs sent.. maybe I'll look into adding halt clearing for > those too.. Nah.. that's not correct. Comments for usb_clear_halt() say: * Note that control and isochronous endpoints don't halt, although control * endpoints report "protocol stall" (for unsupported requests) using the * same status code used to report a true stall. Would it help if we would send the halt clear control urb directly from the completion callback, i.e. do asynchronousy what the usb_clear_halt() does synchronously? -- http://www.iki.fi/~ananaza/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Anubis Electronics "Lifeview"(0x10fd:0x1513)
Hi, Aapo Tahkola schrieb: > On Sat, 3 Mar 2007 03:10:41 +0200 > Aapo Tahkola <[EMAIL PROTECTED]> wrote: > >> On Fri, 02 Mar 2007 23:06:15 +0100 >> Pierre Willenbrock <[EMAIL PROTECTED]> wrote: >> >>> Michael Krufky schrieb: Pierre Willenbrock wrote: > Hi list, > > I am owner of a "MSI DIGIVOX mini-II". I got it to work using the > attached patch and firmware. The patch and firmware are the > result of analyzing some usb logs from windows. > > The patch breaks all users of tda10046, as i don't understand how > that chip is supposed to work. The same goes for my driver > implementation of the Philips 8275a. > > So this mess needs to be fixed before it can go into the > repository. > > The patch is against a fresh hg checkout from > http://linuxtv.org/hg/v4l-dvb at 2007-02-22 21:00 UTC. > > Regards, > Pierre Pierre- I am very happy to hear that you got this device working... Interestingly enough, we have already created a new tda827x dvb fe module, which might be better for your device... This new tda827x module has not yet been merged into the master v4l-dvb repository, but it will be soon. Could you try to use the code located in: http://linuxtv.org/hg/~hhackmann/v4l-dvb The tda827x module will be able to detect the difference between the tda8275 and the tda8275a ... You do not have to fill the callback functions in the config struct -- that is really meant as a hack for some required GPIO handling in the saa7134-dvb driver for input switching. If you can generate a new patch against the repository above, it would make it _much_ easier to integrate your patch into the sources. After you get that done, we can work out the tda1004x differences. You might also want to speak to aett and friedrich, regulars of the #linuxtv irc chat room on irc.freenode.net ... aet is the author of the m920x driver, and friedrich has the same device that you have. They have been working on it, but haven't yet gotten successful results. Good work! Hopefully we can clean this up after you generate a new patch using the tda827x module from hhackmann's repository. Regards, Mike Krufky >>> Hi Mike and Hartmut, >>> >>> this time, the patch does not change tda827x.c at all. I fiddled >>> with the PHY2 value in tda1004x.c and found it to be related to the >>> IF(there seems to be some factor between the IF and PHY2 introduced >>> somewhere else). This leaves some differences in tda1004x.c. I don't >>> know what to do with these, so i would be glad to get any hints. >> >> Updated patch. I'm fine with these m920x changes. >> > > Signed-of-by: Aapo Tahkola <[EMAIL PROTECTED]> > PHY2 indeed defines the IF frequency relative to the sampling frequency. If you need a different value here, the reason most probably is the following: In some countries, i.e. Britain, France and Australia, the tranmitters are +/- 166kHz off the channel center frequency. This isn't documented. You can compensate this by simply tuning to the actually used channel center frequency. A note: Some channel decoders can compensate this offset automatically. The tda10046 needs assistance from the driver for this. This is not built in yet. Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [PATCH] Make saa7134-dvb less noisy
Hi,
Trent Piepho schrieb:
> Tim Small wrote:
>> I use mythtv, and this periodically opens DVB cards to check for new EIT
>> data. Because of this, I end up with hundreds of:
>>
>> mt352_pinnacle_init called
>>
>> lines in my kernel log.
>>
>> The attached patch makes saa7134-dvb quieter.
>
> This patch looks to be against an older version of the saa7134-dvb driver.
> The current version already has a dprintk macro and a debug parameter.
>
> I've made a patch against the current version of the driver which should
> clean up all the printk()s. There were several that are changed from
> printk to dprintk, and some others that have a level like KERN_WARNING or
> KERN_ERR added. I also tried to make the format consistent. The dprintk
> macro wasn't safe. e.g.
> if(!working)
> dprintk("foo");
> else
> whatever();
>
> Wouldn't do what you might expect! That's been fixed too.
>
> Patch is here:
> http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=b7320b447a26;style=gitweb
>
ACK
Will you ask Mauro to pull this or should i apply it to my repository?
Hartmut
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem on SAA7134 Asustek (Tiger or Jayhawk components : 1043:4871) : HELP !
Hi, Emmanuel Emmanuel Quémener schrieb: > Hartmut Hackmann a écrit : > >> Hi, Emmanuel >> >> Emmanuel Quémener schrieb: >> >>> Emmanuel Quémener a écrit : >>> >>> Hartmut Hackmann a écrit : > I noticed 2 things: > > > >> tuner 2-004b: AGC2 gain is: 10 >> >> >> > This means maximum gain. With active LNA, i would expect lower > values... > second: The reason for the tumbling channel decoder might be a > not closed AGC loop. > But if DVB-T works after analog was on once with tuner_config 3, > this leads me to this: > Analog - digital mode switch might be GPIO22 like it is with some > ADS / Lifeview cards. Did you ever try card=87? > But this would cause trouble with the LNA since in the Philips > solutions, GPIO22 always is involved. > Are you sure the board has a LNA? In the philips designs, it sits > under the tuner shield and looks like a SMD voltage regulator. > If there is a LNA, the board seems to have a mode switch we haven't > seen yet. Except - did you try to invert tda1004x GPIO1, so > .gpio_config = TDA10046_GP00_I, > instead > .gpio_config = TDA10046_GP01_I, > > Maybe this helps > Hartmut > > > > I will do it this evening. So, if I sum up, there are 2 tests to perform : - #1 : try to change board from 109 to 87 : in this case, must I get an clean archive or do I keep some changes to tuner_config reference ? - #2 : try to change GPIO config reference : in this case, same as before : clean archive or modified one on tuner_config reference ? Bye EQ Is it necessary to keep tuner_config=3 to definitions or must I get a not modified archive to try to change my board from 109 to 87 and change only GPIO config >>> Sorry, but I didn't take the time in the past 2 weeks to experiment the >>> tests you'd like. >>> >>> I try on last sunday to compile a new kernel (the last one : 2.6.20) >>> with a blank repository on v4l-dvb archive and make the changes on it : >>> it sucks !!! >>> >>> - the new kernel 2.6.20 does not recognized my board >>> - when I try to compile new repository and install the modules, the >>> saa7134 module doesn't want to load >>> - when I search in files saa7134-dvb.c and saa-7134-cards.c the >>> references to tuner_config, It was impossible to find them >>> >>> So, my questions : >>> - how is it possible for me to compile last kernel 2.6.20 with third >>> party v4l-dvb archives ? >>> - when can I get this 2.6.20 working archives ? >>> - what modifications can I perform to test and make working my board >>> (1043:4871 reference)... >>> >>> >> Please use my personal repository for the tests. It is at: >> http://linuxtv.org/hg/~hhackmann/v4l-dvb >> It does compile on kernel 2.6.20, i have it running here. >> Just to be sure: >> - if you compiled for another kernel before, you need to >> delete the file v4l/.version >> - don't try to merge the files into the kernel, compile them separately >> with make, make install (for the install, you need to be root >> - never mix modules with older versions. >> - afik, you need to enable the v4l and dvb stuff in the kernel tree. >> >> Looks like you missed a mail from me, i will just paste it here: >> >> I had a look at the eeprom dump again: The card should be a copy of the >> Tiger-S >> reference design without radio. So please try this: >> Get a copy of my personal repository, compile and install. Then do: >> modprobe saa7134 card=109 secam=l >> modprobe saa7134-alsa >> modprobe saa7134-dvb >> This should do it as long as there are not tricks with the windows driver. >> >> You sould no longer need to load the saa7134-alsa and saa7134-dvb modules >> manually. >> >> Good luck >> Hartmut >> >> >> ___ >> linux-dvb mailing list >> linux-dvb@linuxtv.org >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb >> >> > I've just compiled the modules on a fresh 2.6.20.1 kernel and the output > is badly following : > > saa7134: disagrees about version of symbol videobuf_streamoff > saa7134: Unknown symbol videobuf_streamoff > saa7134: disagrees about version of symbol videobuf_poll_stream > saa7134: Unknown symbol videobuf_poll_stream > saa7134: disagrees about version of symbol videobuf_read_stop > saa7134: Unknown symbol videobuf_read_stop > saa7134: disagrees about version of symbol videobuf_dma_free > saa7134: Unknown symbol videobuf_dma_free > saa7134: disagrees about version of symbol videobuf_reqbufs > saa7134: Unknown symbol videobuf_reqbufs > saa7134: Unknown symbol ir_codes_encore_enltv > saa7134: disagrees about version of symbol videobuf_waiton > saa7134: Unknown symbol videobuf_waiton > saa7134: disagrees about version of symbol videobuf_dqbuf > saa7134:
Re: [linux-dvb] [PATCH] dvb-core: Fix several locking related problems.
On Mon, Mar 05, 2007 at 06:19:01PM +0100, Oliver Endriss wrote: > > From 'Linux Device Drivers' (replace 'down' by 'mutex_lock'): > | ... > | down decrements the value of the semaphore and waits as long as need > | be. down_ interruptible does the same, but the operation is > | interruptible. The interruptible version is almost always the one you > | will want; it allows a user-space process that is waiting on a > | semaphore to be interrupted by the user. You do not, as a general > > | rule, want to use noninterruptible operations unless there truly is no > ^^ > | alternative. Noninterruptible operations are a good way to create > ^^^ > | unkillable processes (the dreaded D state seen in ps), and annoy > | your users. Using down_interruptible requires some extra care, > | however, if the operation is interrupted, the function returns a > | nonzero value, and the caller does not hold the semaphore. Proper use > | of down_interruptible requires always checking the return value and > | responding accordingly. > | ... I don't think this advice applies to mutexes (at least if the mutexes are used in the usual way to protect some common data). For event semaphores, you block waiting for an event, and if the event doesn't happen (maybe you wait for an irq), you need a way out or you're screwed. So using down_interruptible() is what you want. Mutexes, however, are supposed to be held only while manipulating some shared data. So the code looks *always* like this: mutex_lock(&mtx); do_something_with_shared_data(); mutex_unlock(&mtx); Now if some process sleeps uninterruptibly in mutex_lock(), some other process holds the mutex and sleeps in do_something(). If it wedges up, you either have some locking bug (someone forgot a mutex_unlock()), or it wedged up in do_something(), and you got to fix *that*. mutex_unlock_interruptible() would only help to paper over locking bugs, and its use in dvb-core comes from a straight conversion from down_interruptible(), which itself was used because it was once useful during development. How that the signal handling was found to be buggy I think it's much better to use mutex_lock() instead of fixing the mutex_unlock_interruptible() usage. BTW, some statistics: linux-2.6.20$ grep -r '\' . | wc -l 3080 linux-2.6.20$ grep -r '\' . | wc -l 236 Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: [PATCH] Make saa7134-dvb less noisy
Trent Piepho wrote: This patch looks to be against an older version of the saa7134-dvb driver. The current version already has a dprintk macro and a debug parameter. Fair enough, I should have checked svn ;o). I was just using 2.6.20. The only thing I will say is that it might be nicer if the source file name (or module name) and possibly line number were mentioned in the debug printout.. Thanks, Tim. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: [PATCH] Make saa7134-dvb less noisy
Tim Small wrote:
> I use mythtv, and this periodically opens DVB cards to check for new EIT
> data. Because of this, I end up with hundreds of:
>
> mt352_pinnacle_init called
>
> lines in my kernel log.
>
> The attached patch makes saa7134-dvb quieter.
This patch looks to be against an older version of the saa7134-dvb driver.
The current version already has a dprintk macro and a debug parameter.
I've made a patch against the current version of the driver which should
clean up all the printk()s. There were several that are changed from
printk to dprintk, and some others that have a level like KERN_WARNING or
KERN_ERR added. I also tried to make the format consistent. The dprintk
macro wasn't safe. e.g.
if(!working)
dprintk("foo");
else
whatever();
Wouldn't do what you might expect! That's been fixed too.
Patch is here:
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=b7320b447a26;style=gitweb
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: DVB-H information
> > I found on Internet a free application to extract PES or ES from a TS, > > but don't know how I can 'de-packetize' the RTP/UDP/IP stack to > > visualize the raw H.264 stream. Do you know application in order to do > > it? > > I used dvbnet apps (available with Linux DVB) to receive datagrams from > TS on a virtual net interface and routing to a multicast group. > Then you should be able to dump the H.264 ES with mplayer, > I used VLC to watch audio and video. > > regards, > Francesco Hello Francesco, I've tried without any succes to read DVB-H streams throught dvbnet and VLC. I only use tcpdump to extract packets from dvbnet interface. How do you route to a multicast group and read with VLC ? For your information, I've started (first step) to write a library to decode ESG in order to obtain SDP (aka PMT like in DVB-H systems) Please see DVB-APPS repository for LIBESG : http://linuxtv.org/hg/dvb-apps?mf=8b37590c8695;path=/lib/libesg/;style=gitweb Regards, Stephane ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [Patch] USBVision - Add some additional devices to the driver and modified some device descriptions
-Add some missing Hauppauge and Belkin devices to the driver. -Fixed up some device descriptions. Signed-off-by: Dwaine P. Garden [EMAIL PROTECTED] USBVision-AdditionalDevices.patch Description: Binary data ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] dvb-core: Fix several locking related problems.
On 05/03/07 17:19, Oliver Endriss wrote: Simon Arlott wrote: On Mon, March 5, 2007 11:19, Johannes Stezenbach wrote: On Mon, Mar 05, 2007 at 01:58:14AM +0100, Oliver Endriss wrote: Simon Arlott wrote: Is any part of the patch going to be applied? I mentioned this problem in September last year and it looks like it's existed for years (the semaphore locking did the same thing). Well, I hoped that someone more familiar with the demuxer stuff would comment on the patch. I am not very happy about using non-interruptible lock operations... Why? If there are deadlocks these should be fixed, not ignored. Yes, they should be fixed, but they should not require a reboot. What!? The fix for a deadlock is not a reboot... perhaps you misunderstood what I meant - whatever ends up holding the lock forever should be fixed. From 'Linux Device Drivers' (replace 'down' by 'mutex_lock'): | ... | down decrements the value of the semaphore and waits as long as need | be. down_ interruptible does the same, but the operation is | interruptible. The interruptible version is almost always the one you | will want; it allows a user-space process that is waiting on a | semaphore to be interrupted by the user. You do not, as a general | rule, want to use noninterruptible operations unless there truly is no ^^ | alternative. Noninterruptible operations are a good way to create ^^^ | unkillable processes (the dreaded D state seen in ps), and annoy ^^ | your users. Using down_interruptible requires some extra care, ^^ I don't see this advice in Documentation/mutex-design.txt (although it doesn't advise either way) or in Documentation/ at all. ^ | however, if the operation is interrupted, the function returns a | nonzero value, and the caller does not hold the semaphore. Proper use | of down_interruptible requires always checking the return value and ^ Until you do this, you can't use down_interruptible. | responding accordingly. | ... Anyway, I'll apply the patch to HG master if you submit an updated patch: - Please add a line of comment to each mutex_lock() stating _why_ the non-interruptible lock has to be used at this place. What's the point of doing that? The point is to document why we do not use the interruptible version. Next year someone might submit a patch replacing mutex_lock by mutex_lock_interruptible, and no one remembers why mutex_lock is required at this place. There is no danger of this, if someone submits a patch replacing it with mutex_lock_interruptible and doesn't take into account every possible calling function's check of the return value then their patch needs changing before it can be accepted. IMHO using mutex_lock_interruptible() is almost always wrong. The only use it has in dvb-core is to recover from locking bugs -- if it deadlocks you can Ctrl-C out of it (instead of being left with a non-killable program -> reboot). The key phrase here is "locking *bugs*", if the code can lock forever it needs to be fixed. The real cause of bugs will never be found if interruptible locking is used everywhere when when it's not necessary :( Also, this is in dvb-core not actual card drivers - why would there be locking bugs in dvb-core itself? This is what lockdep is for. Is lockdep activated in distribution kernels? No, but developers could use it while testing. It only reports locking bugs by checking how locks depend on other locks (see lockdep-design.txt), I don't think it would spot code that just locked a mutex and then waited forever (which is really bad code anyway). -- Simon Arlott ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Marco's Opera driver fails load firmware
Hi Marco, I just tested your driver you have posted to the linux-dvb mailing list. I have problem load firmware into device: usb 5-3: new high speed USB device using ehci_hcd and address 4 usb 5-3: configuration #1 chosen from 1 choice dvb-usb: found a 'Opera1 DVB-S USB2.0' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'opera1.fw' dvb-usb: firmware download failed at 9418 with -22 opera1: probe of 5-3:1.0 failed with error -22 usbcore: registered new interface driver opera1 My firmware files are: -rw-r--r-- 1 root root 8300 2006-04-05 21:23 opera1-2.fw -rw-r--r-- 1 root root 55894 2006-04-05 21:23 opera1-fpga.fw -rw-r--r-- 1 root root 9432 2006-04-05 21:22 opera1.fw 60aa3e8a540de75d0f456d3979408d7d /usr/lib/hotplug/firmware/opera1-2.fw 2b48b0923de2fdfcb160d9cce3d3529d /usr/lib/hotplug/firmware/opera1-fpga.fw 95032d7201b25e0f8ee802c5b292aa69 /usr/lib/hotplug/firmware/opera1.fw I have created wish in kernel's bugzilla before, so we can track it there: http://bugzilla.kernel.org/show_bug.cgi?id=7574 Thanks for help. Michal ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] dvb-core: Fix several locking related problems.
Simon Arlott wrote: > On Mon, March 5, 2007 11:19, Johannes Stezenbach wrote: > > On Mon, Mar 05, 2007 at 01:58:14AM +0100, Oliver Endriss wrote: > >> Simon Arlott wrote: > >> > Is any part of the patch going to be applied? I mentioned this > >> > problem in September last year and it looks like it's existed for > >> > years (the semaphore locking did the same thing). > >> > >> Well, I hoped that someone more familiar with the demuxer stuff would > >> comment on the patch. I am not very happy about using non-interruptible > >> lock operations... > > Why? If there are deadlocks these should be fixed, not ignored. Yes, they should be fixed, but they should not require a reboot. From 'Linux Device Drivers' (replace 'down' by 'mutex_lock'): | ... | down decrements the value of the semaphore and waits as long as need | be. down_ interruptible does the same, but the operation is | interruptible. The interruptible version is almost always the one you | will want; it allows a user-space process that is waiting on a | semaphore to be interrupted by the user. You do not, as a general | rule, want to use noninterruptible operations unless there truly is no ^^ | alternative. Noninterruptible operations are a good way to create ^^^ | unkillable processes (the dreaded D state seen in ps), and annoy | your users. Using down_interruptible requires some extra care, | however, if the operation is interrupted, the function returns a | nonzero value, and the caller does not hold the semaphore. Proper use | of down_interruptible requires always checking the return value and | responding accordingly. | ... > >> Anyway, I'll apply the patch to HG master if you submit an updated patch: > >> - Please add a line of comment to each mutex_lock() stating _why_ the > >> non-interruptible lock has to be used at this place. > > What's the point of doing that? The point is to document why we do not use the interruptible version. Next year someone might submit a patch replacing mutex_lock by mutex_lock_interruptible, and no one remembers why mutex_lock is required at this place. > > IMHO using mutex_lock_interruptible() is almost always wrong. > > > > The only use it has in dvb-core is to recover from locking bugs -- > > if it deadlocks you can Ctrl-C out of it > > (instead of being left with a non-killable program -> reboot). > > This is what lockdep is for. Is lockdep activated in distribution kernels? > > But with mutex_lock_interruptible() it's easy to introduce > > signal handling bugs, which Simon confirmed to exist. > > It's also easy to find examples of people needing to rmmod/modprobe > because dvr0 started returning -EBUSY on open() after they closed > something. You can find examples for everything. A reboot because of a deadlock is worse than a rmmod/insmod cycle. Anyway, that's not the point. > > Fixing those up without reverting to mutex_lock() way might > > be possible, but is more difficult. > > It'd introduce lot of unneccessary -ERESTARTSYS, just to avoid the > possiblity of waiting on mutex_lock for a few msecs. Imho they are not unneccessary, it's a question of programming style. See above. Oliver -- VDR Remote Plugin 0.3.9 available at http://www.escape-edv.de/endriss/vdr/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] pxsup2dast.c revision 504 has stupid bug.
Hi Anyone using pxsup2dast.c (http://www.iki.fi/too/sw/m2vmp2cut/pxsup2dast.c) should upgrade it to (svn) revision 1280, as earlyer version (r504) has really stupid bug -- so stupid I wonder how it could have worked. anyway, the updated version is available at above url. If you know anyone using the older version and is not on this list, please inform such users :D Tomi ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [PATCH] Make saa7134-dvb less noisy
I use mythtv, and this periodically opens DVB cards to check for new EIT
data. Because of this, I end up with hundreds of:
mt352_pinnacle_init called
lines in my kernel log.
The attached patch makes saa7134-dvb quieter.
Cheers,
Tim.
signed-off-by: Tim Small <[EMAIL PROTECTED]>
--- linux-source-2.6.20/drivers/media/video/saa7134/saa7134-dvb.c.orig 2007-03-05 15:28:36.0 +
+++ linux-source-2.6.20/drivers/media/video/saa7134/saa7134-dvb.c 2007-03-05 15:57:45.0 +
@@ -54,6 +54,15 @@
module_param(use_frontend, int, 0644);
MODULE_PARM_DESC(use_frontend,"for cards with multiple frontends (0: terrestrial, 1: satellite)");
+static int debug = 0;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "Turn on/off saa7134-dvb debugging (default:off).");
+
+#define dprintk(args...) \
+ do { if (debug) { printk(KERN_DEBUG "%s: %s()[%d]: ", KBUILD_MODNAME, __FUNCTION__, __LINE__); printk(args); } } while (0)
+
+
+
/* -- */
static int pinnacle_antenna_pwr(struct saa7134_dev *dev, int on)
{
@@ -75,7 +84,7 @@
saa_setl(SAA7134_GPIO_GPSTATUS0 >> 2, (1 << 28));
udelay(10);
ok = saa_readl(SAA7134_GPIO_GPSTATUS0) & (1 << 27);
- printk("%s: %s %s\n", dev->name, __FUNCTION__,
+ dprintk("%s: %s %s\n", dev->name, __FUNCTION__,
ok ? "on" : "off");
if (!ok)
@@ -96,7 +105,7 @@
static u8 irq_cfg [] = { INTERRUPT_EN_0, 0x00, 0x00, 0x00, 0x00 };
struct saa7134_dev *dev= fe->dvb->priv;
- printk("%s: %s called\n",dev->name,__FUNCTION__);
+ dprintk("%s: %s called\n",dev->name,__FUNCTION__);
mt352_write(fe, clock_config, sizeof(clock_config));
udelay(200);
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] flexcop_pci / lockdep irq BUG?
Hi, I'm having trouble with my mythtv server locking up hard after approx every 8 hours on average - apparently no such problems when I tried installing W2K on the same hardware. Anyway, having enabled various kernel debugging options, I've seen this pop out of the kernel messages: Mar 5 14:07:40 etchtest kernel: BUG: at kernel/lockdep.c:1860 trace_hardirqs_on() Mar 5 14:07:40 etchtest kernel: Mar 5 14:07:40 etchtest kernel: Call Trace: Mar 5 14:07:40 etchtest kernel:[] trace_hardirqs_on+0xc4/0x150 Mar 5 14:07:40 etchtest kernel: [] _spin_unlock_irq+0x2b/0x31 Mar 5 14:07:40 etchtest kernel: [] :b2c2_flexcop_pci:flexcop_pci_isr+0x130/0x13c Mar 5 14:07:40 etchtest kernel: [] handle_IRQ_event+0x20/0x55 Mar 5 14:07:40 etchtest kernel: [] handle_fasteoi_irq+0x95/0xd5 Mar 5 14:07:40 etchtest kernel: [] do_IRQ+0x114/0x170 Mar 5 14:07:40 etchtest kernel: [] ret_from_intr+0x0/0xf Mar 5 14:07:40 etchtest kernel: I've had a very quick look at the code, but can't really tell whether the bug in question is with the flexcop_pci driver, or the lockdep code... The box is running 2.6.20 (+ Debian patches), on an Intel Core2 Duo mobile. SMP is enabled. I can compile a stock kernel if that'd be more useful. Tim. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: DVB-H information
Paolo Pasquali wrote: > Thanks a lot Francesco. > So, I have a recorded TS on my PC. With dvbnet apps I 'open' the *.ts > and 'send' the ts to be dump to mplayer. Is it right? No, dvbnet needs a real DVB adapter supported by a linux-dvb kernel module, so it is an online solution. If you have a recorded TS you can try with dvbloopback module, never tried myself though. regards, Francesco ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem on SAA7134 Asustek (Tiger or Jayhawk components : 1043:4871) : HELP !
Hartmut Hackmann a écrit : > Hi, Emmanuel > > Emmanuel Quémener schrieb: > >> Emmanuel Quémener a écrit : >> >> >>> Hartmut Hackmann a écrit : >>> >>> >>> I noticed 2 things: > tuner 2-004b: AGC2 gain is: 10 > > > This means maximum gain. With active LNA, i would expect lower values... second: The reason for the tumbling channel decoder might be a not closed AGC loop. But if DVB-T works after analog was on once with tuner_config 3, this leads me to this: Analog - digital mode switch might be GPIO22 like it is with some ADS / Lifeview cards. Did you ever try card=87? But this would cause trouble with the LNA since in the Philips solutions, GPIO22 always is involved. Are you sure the board has a LNA? In the philips designs, it sits under the tuner shield and looks like a SMD voltage regulator. If there is a LNA, the board seems to have a mode switch we haven't seen yet. Except - did you try to invert tda1004x GPIO1, so .gpio_config = TDA10046_GP00_I, instead .gpio_config = TDA10046_GP01_I, Maybe this helps Hartmut >>> I will do it this evening. >>> >>> So, if I sum up, there are 2 tests to perform : >>> - #1 : try to change board from 109 to 87 : in this case, must I get an >>> clean archive or do I keep some changes to tuner_config reference ? >>> - #2 : try to change GPIO config reference : in this case, same as >>> before : clean archive or modified one on tuner_config reference ? >>> >>> Bye >>> >>> EQ >>> >>> Is it necessary to keep tuner_config=3 to definitions or must I get a >>> not modified archive to try to change my board from 109 to 87 and change >>> only GPIO config >>> >>> >> Sorry, but I didn't take the time in the past 2 weeks to experiment the >> tests you'd like. >> >> I try on last sunday to compile a new kernel (the last one : 2.6.20) >> with a blank repository on v4l-dvb archive and make the changes on it : >> it sucks !!! >> >> - the new kernel 2.6.20 does not recognized my board >> - when I try to compile new repository and install the modules, the >> saa7134 module doesn't want to load >> - when I search in files saa7134-dvb.c and saa-7134-cards.c the >> references to tuner_config, It was impossible to find them >> >> So, my questions : >> - how is it possible for me to compile last kernel 2.6.20 with third >> party v4l-dvb archives ? >> - when can I get this 2.6.20 working archives ? >> - what modifications can I perform to test and make working my board >> (1043:4871 reference)... >> >> > Please use my personal repository for the tests. It is at: > http://linuxtv.org/hg/~hhackmann/v4l-dvb > It does compile on kernel 2.6.20, i have it running here. > Just to be sure: > - if you compiled for another kernel before, you need to > delete the file v4l/.version > - don't try to merge the files into the kernel, compile them separately > with make, make install (for the install, you need to be root > - never mix modules with older versions. > - afik, you need to enable the v4l and dvb stuff in the kernel tree. > > Looks like you missed a mail from me, i will just paste it here: > > I had a look at the eeprom dump again: The card should be a copy of the > Tiger-S > reference design without radio. So please try this: > Get a copy of my personal repository, compile and install. Then do: > modprobe saa7134 card=109 secam=l > modprobe saa7134-alsa > modprobe saa7134-dvb > This should do it as long as there are not tricks with the windows driver. > > You sould no longer need to load the saa7134-alsa and saa7134-dvb modules > manually. > > Good luck > Hartmut > > > ___ > linux-dvb mailing list > linux-dvb@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > > I've just compiled the modules on a fresh 2.6.20.1 kernel and the output is badly following : saa7134: disagrees about version of symbol videobuf_streamoff saa7134: Unknown symbol videobuf_streamoff saa7134: disagrees about version of symbol videobuf_poll_stream saa7134: Unknown symbol videobuf_poll_stream saa7134: disagrees about version of symbol videobuf_read_stop saa7134: Unknown symbol videobuf_read_stop saa7134: disagrees about version of symbol videobuf_dma_free saa7134: Unknown symbol videobuf_dma_free saa7134: disagrees about version of symbol videobuf_reqbufs saa7134: Unknown symbol videobuf_reqbufs saa7134: Unknown symbol ir_codes_encore_enltv saa7134: disagrees about version of symbol videobuf_waiton saa7134: Unknown symbol videobuf_waiton saa7134: disagrees about version of symbol videobuf_dqbuf saa7134: Unknown symbol videobuf_dqbuf saa7134: disagrees about version of symbol videobuf_queue_init saa7134: Unknown symbol videobuf_queue_init saa7134: Unknown symbol ir_rc5_timer_keyup saa7134: Unknow
[linux-dvb] Re: DVB-H information
Paolo Pasquali wrote: Hi to all, I'm Paolo Pasquali, Telecommunications engineer, and I'm working on the DVB-H TS quality. This is the first time I post in this mailing-list. I have a problem with a DVB-H Transport Stream. What kind of problem? I found on Internet a free application to extract PES or ES from a TS, but don't know how I can 'de-packetize' the RTP/UDP/IP stack to visualize the raw H.264 stream. Do you know application in order to do it? I used dvbnet apps (available with Linux DVB) to receive datagrams from TS on a virtual net interface and routing to a multicast group. Then you should be able to dump the H.264 ES with mplayer, I used VLC to watch audio and video. regards, Francesco ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-H information
I would imagine TSReader from http://www.coolstf.com/tsreader/ would do the job nicely. Of course, its a Windows app. -t On 3/5/07, Paolo Pasquali <[EMAIL PROTECTED]> wrote: Hi to all, I'm Paolo Pasquali, Telecommunications engineer, and I'm working on the DVB-H TS quality. This is the first time I post in this mailing-list. I have a problem with a DVB-H Transport Stream. I have a DVB-H TS recorder on my PC and I need to demultiplex the file in order to analyze a single H.264 stream. I found on Internet a free application to extract PES or ES from a TS, but don't know how I can 'de-packetize' the RTP/UDP/IP stack to visualize the raw H.264 stream. Do you know application in order to do it? Thanks a lot in advance for ypur support. Best Regards, Paolo ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] DVB-H information
Hi to all, I'm Paolo Pasquali, Telecommunications engineer, and I'm working on the DVB-H TS quality. This is the first time I post in this mailing-list. I have a problem with a DVB-H Transport Stream. I have a DVB-H TS recorder on my PC and I need to demultiplex the file in order to analyze a single H.264 stream. I found on Internet a free application to extract PES or ES from a TS, but don't know how I can 'de-packetize' the RTP/UDP/IP stack to visualize the raw H.264stream. Do you know application in order to do it? Thanks a lot in advance for ypur support. Best Regards, Paolo ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] dvb-core: Fix several locking related problems.
On Mon, March 5, 2007 11:19, Johannes Stezenbach wrote: > On Mon, Mar 05, 2007 at 01:58:14AM +0100, Oliver Endriss wrote: >> Simon Arlott wrote: >> > Is any part of the patch going to be applied? I mentioned this >> > problem in September last year and it looks like it's existed for >> > years (the semaphore locking did the same thing). >> >> Well, I hoped that someone more familiar with the demuxer stuff would >> comment on the patch. I am not very happy about using non-interruptible >> lock operations... Why? If there are deadlocks these should be fixed, not ignored. >> Anyway, I'll apply the patch to HG master if you submit an updated patch: >> - Please add a line of comment to each mutex_lock() stating _why_ the >> non-interruptible lock has to be used at this place. What's the point of doing that? > IMHO using mutex_lock_interruptible() is almost always wrong. > > The only use it has in dvb-core is to recover from locking bugs -- > if it deadlocks you can Ctrl-C out of it > (instead of being left with a non-killable program -> reboot). This is what lockdep is for. > But with mutex_lock_interruptible() it's easy to introduce > signal handling bugs, which Simon confirmed to exist. It's also easy to find examples of people needing to rmmod/modprobe because dvr0 started returning -EBUSY on open() after they closed something. > Fixing those up without reverting to mutex_lock() way might > be possible, but is more difficult. It'd introduce lot of unneccessary -ERESTARTSYS, just to avoid the possiblity of waiting on mutex_lock for a few msecs. -- Simon Arlott ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] dvb-core: Fix several locking related problems.
On Mon, Mar 05, 2007 at 01:58:14AM +0100, Oliver Endriss wrote: > Simon Arlott wrote: > > Is any part of the patch going to be applied? I mentioned this > > problem in September last year and it looks like it's existed for > > years (the semaphore locking did the same thing). > > Well, I hoped that someone more familiar with the demuxer stuff would > comment on the patch. I am not very happy about using non-interruptible > lock operations... > > Anyway, I'll apply the patch to HG master if you submit an updated patch: > - Please add a line of comment to each mutex_lock() stating _why_ the > non-interruptible lock has to be used at this place. IMHO using mutex_lock_interruptible() is almost always wrong. The only use it has in dvb-core is to recover from locking bugs -- if it deadlocks you can Ctrl-C out of it (instead of being left with a non-killable program -> reboot). But with mutex_lock_interruptible() it's easy to introduce signal handling bugs, which Simon confirmed to exist. Fixing those up without reverting to mutex_lock() way might be possible, but is more difficult. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
