Re: [linux-dvb] saa7146_i2c_writeout: timed out waiting for end of xfer
Oliver Endriss wrote: Hi Oliver, Please try the current HG driver. (Important because timeouts are now logged in poll mode, too.) I downloaded the refactoring driver from the bz2-link on this page: http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-refactoring and compiled them. If it still happens, please replace SAA7146_USE_I2C_IRQ by SAA7146_I2C_SHORT_DELAY in av7110.c. Does it help? With the new driver I still got the error message :-(. But it looks slightly different than before: saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer. I presume the (1) is the second registered frontend. Well this is my budget-ci card and not the FF-Card... So I thought I might as well try your advice for the FF card for the budget card and changed the flag in budget-ci.c to SAA7146_I2C_SHORT_DELAY. Now the error message that shows is: saa7146_i2c_writeout [poll]: timed out waiting for end of xfer Until now I thought that the motherboard change had caused this problem, but at the same I have replace the S1400 with an S1500 with a CI connected to it. I now have an Asus M2NPV-VM(NVidia GeForce 6150 + nForce 430) with an Athlon64 3200+ and 512MB DDR2 RAM(667). I am running Debian Etch x86_64 with kernel 2.6.20+refactoring driver. Maybe some of the above might give you a clue on what could be the cause of the problem. Thank you for looking into the problem. Have a nice weekend. André ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Userspace tuner
Dont bother xc2028-fe is STILL A PATCH. Getting the dual4 working for .au still requires PATCHES What time is it? I'm not complaining. Since it works. But Please consider ( or dont) Even if certain developers did not exist in this dimension. You would still be stuck where you are now. Only with less people to blame. Regards Jules. On Sat, 18 Aug 2007, CityK wrote: Dâniel Fraga wrote: I've been exchanging e-mails with Markus for months and he supported very well my board (cx88 chip with xc2028 tuner). Yes, Markus is very good (exceptionally good in fact) with helping users. But at the same time, I noticed that there's a disagreement between Markus and the maintainers and I think this is counterproductive. As far as I know there's a lot of code to be merged in the kernel and we, the users, are waiting for months to see that. If the maintainers keep discussing everything to death, it won't get any further. So please, let's work together and reach the objective. Markus Rechberger wrote: The reason is that the linuxtv project depends on people who have their own ideas and do not care about other solutions or temporary solutions to get things done Now Markus: a) That comment certainly isn't very cooperative or indicative of good will ... and most certainly not in concert with what many of your supporters wish (i.e. just look at the concluding sentence in Daniel's comment). I previously told you once already, in a private email, that if you have truly moved on from LinuxTV, then leave it at that, and stop with the parting shots/insults. After all, you have yourself asked on several occasions on the mailing list for discussion on the matter to cease. So what's good for the goose should be good for the gander. b) Your comment is highly hypocritical on another level too. Consider comments from the [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88 thread on the mailing list this past May: Quoting M.Krufky ( from: http://www.linuxtv.org/pipermail/linux-dvb/2007-May/018016.html): If we decide to go this route, it will truly be the best compromise -- It will allow us to merge in support for the sixty some-odd devices that Markus is talking about, and it will allow for easy development of newer devices that use this tuner ic. The major benefit of this method is that it _will_ allow for us developers to put our heads together after the fact, and find better ways of supporting hybrid tuners. At that point, the pressure of 'trying to merge support for sixty devices' will be gone. Developers will finally be able to discuss this issue without the pressure of the current pending issues, and we _will_ be able to find a better solution. As far as I can tell, it seems that this is the only way for us to push this through, while not upsetting other developers. I will volunteer to keep up the maintenance of the xc3028-fe module until that proper, better solution is agreed upon. Quoting M. Rechberger (http://www.linuxtv.org/pipermail/linux-dvb/2007-May/018084.html): This is not acceptable for me anymore As I stated in my last message in this thread, and as others have stated before on several occasions, temporary solutions to get things done were available, only you choose not to follow such courses.Live with that decision and follow your path. But don't pretend it was otherwise. ___ 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
Re: [linux-dvb] [PATCH] add device node locking possibility to dvbcore
On Fri, 17 Aug 2007, Markus Rechberger wrote: as I wrote earlier the thread can be idle/closed even before the node gets closed (you can test that with kaffeine, and you can test the other case with the scan utility) How can this happen? Afaics the fe thread may continue to exist after the device node was closed, but not vice-versa. Yes, how can that happen? What will make the dvb frontend thread exit before the device is closed? Maybe it would be a good idea to do what Andreas suggested and have the frontend release function block until the frontend thread has exited. AFAIK, the thread hanging around after the device is closed does nothing but cause problems. It's a very common FAQ, Q: Why does it mythtv not work if I change from a digital channel to an analog one? A: You need to set dvb_shutdown_timeout to 0. What's the purpose of dvb_shutdown_timeout 0? ts_bus_ctrl does a kind of reference counting. For readers: - fe-ops.ts_bus_ctrl(fe,1) is called during open - fe-ops.ts_bus_ctrl(fe,0) is called during close For the one and only writer: - fe-ops.ts_bus_ctrl(fe,1) is called during open - fe-ops.ts_bus_ctrl(fe,0) is called when the thread exits, usually after close So, how do you tell if the ts bus is already locked? I didn't want to write it but this is also what I would do, and I would also include the other dvb device nodes.. it doesn't make sense to keep them open as non functional dummies, or even allow people to open these nodes if the dvb mode is locked. What about a device with two frontends? Maybe the DVB-T/Analog frontend is locked by the V4L device, but you can still use a DVB-S frontend with dvb. In that case the demux could still be opened and used. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] add device node locking possibility to dvbcore
ts_bus_ctrl does a kind of reference counting. For readers: - fe-ops.ts_bus_ctrl(fe,1) is called during open - fe-ops.ts_bus_ctrl(fe,0) is called during close For the one and only writer: - fe-ops.ts_bus_ctrl(fe,1) is called during open - fe-ops.ts_bus_ctrl(fe,0) is called when the thread exits, usually after close So, how do you tell if the ts bus is already locked? I didn't want to write it but this is also what I would do, and I would also include the other dvb device nodes.. it doesn't make sense to keep them open as non functional dummies, or even allow people to open these nodes if the dvb mode is locked. What about a device with two frontends? Maybe the DVB-T/Analog frontend is locked by the V4L device, but you can still use a DVB-S frontend with dvb. In that case the demux could still be opened and used. This is what i stated multiple times: lock the device bus. It is a device property of a device with a single bus and 2 frontends. (A device driver represents the Hardware configuration, you are not making anything new/revolutionary here) Bus Locking wouldn't be necessary for a device with 2 frontends and 2 buses (ie 1:1 ratio, locking is required in cases other than this 1:1 case). That simple. But the general idea that carried forward was DVB core has to do the locking, rather than individual devices, which was conceptually wrong. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] add device node locking possibility to dvbcore
Hi Obi, Andreas Oberritter wrote: Hi Oliver, Oliver Endriss wrote: ts_bus_ctrl does a kind of reference counting. For readers: - fe-ops.ts_bus_ctrl(fe,1) is called during open - fe-ops.ts_bus_ctrl(fe,0) is called during close For the one and only writer: - fe-ops.ts_bus_ctrl(fe,1) is called during open - fe-ops.ts_bus_ctrl(fe,0) is called when the thread exits, usually after close To properly lock the bridge, fe-ops.ts_bus_ctrl(fe, 1) must be called only when the first user opens the device and fe-ops.ts_bus_ctrl(fe, 0) must be called only when the last user closes the device. I think that the option dvb_shutdown_timeout must be removed to fix the problem, where the frontend thread can be idle after close(). IMHO the thread should always be terminated when the last writer closes the device. The release function should then block until the thread really has terminated. Why would you need the frontend thread to be idle ? If you want the frontend thread to be idle, requiring shutdown timeout to disabled, then i think it makes no sense. (I am not saying it wouldn't work, but that is not a great option.) Possibly, ts_bus_ctrl can be made to return frontend status based on the frontend private semaphore, such that it is safe for other bus activities. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] System load raises when budget_av is loaded
2007/8/18, e9hack [EMAIL PROTECTED]:
I've modified saa7146_wait_for_debi_done() a little bit. The function
returns earlier from the
second loop, if nobusyloop was 0 and if SPCI_DEBI_E was set after 100usec.
I've used udelay() and an
additional counter. My TT-C2300 has reported an ARM boot error. The
unmodified driver wasn't able to
restart the ARM. I must do a power off to recover the TT-C2300. I will do
more test on this issue,
but currently I do some tests on a TT-C1500. Too many challenges are not
so good at the same time.
It seems, the delay of 100usec is too short. During booting of the ARM,
DEBI_E is set for ca. 360usec after some debi commands. I've changed the
delay to 500usec. The load average is dropped from 0.65 to 0.0 with
budget_av and dvb_ttpci loaded and vdr isn't running.
- Hartmut
signed off by: Hartmut Birr [EMAIL PROTECTED]
diff -r dc1611a2006f linux/drivers/media/common/saa7146_core.c
--- a/linux/drivers/media/common/saa7146_core.c Fri Aug 17 17:49:41 2007 -0300
+++ b/linux/drivers/media/common/saa7146_core.c Sat Aug 18 10:45:08 2007 +0200
@@ -63,6 +63,8 @@ int saa7146_wait_for_debi_done(struct sa
{
unsigned long start;
int err;
+ int loop;
+ u32 psr;
/* wait for registers to be programmed */
start = jiffies;
@@ -79,20 +81,31 @@ int saa7146_wait_for_debi_done(struct sa
}
/* wait for transfer to complete */
+ loop = 0;
start = jiffies;
while (1) {
err = time_after(jiffies, start + HZ/4);
- if (!(saa7146_read(dev, PSR) SPCI_DEBI_S))
+ psr = saa7146_read(dev, PSR);
+ if (!(psr SPCI_DEBI_S))
break;
saa7146_read(dev, MC2);
if (err) {
DEB_S((timed out while waiting for transfer completion\n));
return -ETIMEDOUT;
}
- if (nobusyloop)
+ /* leave the loop, if the DEBI_E isn't reset after 500usec */
+ if (loop = 500 (psr SPCI_DEBI_E)) {
+ DEB_S((error while waiting for transfer completion\n));
+ return -EIO;
+ }
+ if (nobusyloop) {
msleep(1);
- }
-
+ loop += 1000;
+ } else {
+ udelay(10);
+ loop += 10;
+ }
+ }
return 0;
}
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] compile problem
Hi, it isn't possible to compile the current v4l-tree with linux 2.6.22.2: very-new-darkstar:/usr/src/v4l-dvb-test # make make -C /usr/src/v4l-dvb-test/v4l make[1]: Entering directory `/usr/src/v4l-dvb-test/v4l' creating symbolic links... make -C /lib/modules/2.6.22.2-test/build SUBDIRS=/usr/src/v4l-dvb-test/v4l modules make[2]: Entering directory `/usr/src/linux-2.6.22.2' CC [M] /usr/src/v4l-dvb-test/v4l/c-qcam.o In file included from /usr/src/v4l-dvb-test/v4l/../linux/include/media/v4l2-dev.h:18, from /usr/src/v4l-dvb-test/v4l/../linux/include/media/v4l2-common.h:29, from /usr/src/v4l-dvb-test/v4l/c-qcam.c:38: include/linux/device.h:533:41: error: macro device_create requires 7 arguments, but only 5 given In file included from /usr/src/v4l-dvb-test/v4l/../linux/include/media/v4l2-dev.h:18, from /usr/src/v4l-dvb-test/v4l/../linux/include/media/v4l2-common.h:29, from /usr/src/v4l-dvb-test/v4l/c-qcam.c:38: include/linux/device.h:534: warning: 'format' attribute only applies to function types make[3]: *** [/usr/src/v4l-dvb-test/v4l/c-qcam.o] Error 1 make[2]: *** [_module_/usr/src/v4l-dvb-test/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6.22.2' make[1]: *** [default] Fehler 2 make[1]: Leaving directory `/usr/src/v4l-dvb-test/v4l' make: *** [all] Fehler 2 very-new-darkstar:/usr/src/v4l-dvb-test # The attached patch does fix this problem. - Hartmut diff -r 96c5b8101ea3 v4l/compat.h --- a/v4l/compat.h Fri Aug 17 03:20:35 2007 -0300 +++ b/v4l/compat.h Sat Aug 18 09:13:24 2007 +0200 @@ -284,7 +284,7 @@ static inline int vm_insert_page(struct # define class_destroy(a) class_simple_destroy(a) #elif LINUX_VERSION_CODE KERNEL_VERSION(2,6,15) # define class_device_create(a, b, c, d, e, f, g, h) class_device_create(a, c, d, e, f, g, h) -#elif LINUX_VERSION_CODE KERNEL_VERSION(2,6,24) +#elif LINUX_VERSION_CODE KERNEL_VERSION(2,6,22) # define device_create(a, b, c, d, e, f, g) class_device_create(a, NULL, c, b, d, e, f, g) # define device_destroy(a, b) class_device_destroy(a, b) #endif ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] add device node locking possibility todvbcore
Trent Piepho wrote: On Fri, 17 Aug 2007, Markus Rechberger wrote: as I wrote earlier the thread can be idle/closed even before the node gets closed (you can test that with kaffeine, and you can test the other case with the scan utility) How can this happen? Afaics the fe thread may continue to exist after the device node was closed, but not vice-versa. Yes, how can that happen? What will make the dvb frontend thread exit before the device is closed? I don't know. I should probably spend sometime reminding myself of the purpose of the thread. Maybe it would be a good idea to do what Andreas suggested and have the frontend release function block until the frontend thread has exited. AFAIK, the thread hanging around after the device is closed does nothing but cause problems. It's a very common FAQ, Q: Why does it mythtv not work if I change from a digital channel to an analog one? A: You need to set dvb_shutdown_timeout to 0. What's the purpose of dvb_shutdown_timeout 0? We should be clear that the ts_bus_ctrl isn't design to lock or version count in any way. The purpose of the callback is to allow the bridge to determine whether the it has sufficient hardware resources to allow the ops open to complete (assuming that the callers wants data). The best example of this todate has been the HVR1300 sub-drivers in which a V4L and DVB ops structures both need to access frontends on the single PCI bus. Having a DVB application interfere with the V4L application's use of the bus isn't acceptable. Personally, I think ts_bus_ctrl needs to be replaced with a single resource allocation/deallocation mechanism that extends beyond simple bus negotiation into tuners, demods, encoders and other devices. ts_bus_ctrl does a kind of reference counting. For readers: - fe-ops.ts_bus_ctrl(fe,1) is called during open - fe-ops.ts_bus_ctrl(fe,0) is called during close For the one and only writer: - fe-ops.ts_bus_ctrl(fe,1) is called during open - fe-ops.ts_bus_ctrl(fe,0) is called when the thread exits, usually after close So, how do you tell if the ts bus is already locked? Until now it's never been a requirement. I didn't want to write it but this is also what I would do, and I would also include the other dvb device nodes.. it doesn't make sense to keep them open as non functional dummies, or even allow people to open these nodes if the dvb mode is locked. What about a device with two frontends? Maybe the DVB-T/Analog frontend is locked by the V4L device, but you can still use a DVB-S frontend with dvb. In that case the demux could still be opened and used. The HVR1300 (and HVR3000 / 4000) prohibit this by using ts_bus_ctrl, these are good examples. - Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Userspace tuner
Markus Rechberger wrote: anyway it's history; we shouldn't waste more time on discussing what happened Indeed. However, you have continued to do so, and in an inflammatory fashion -- and that is just not going to escape attention. As I've indicated to you earlier -- if the issue is truly at an end, then let it go and stop with the insults/parting shots etc. (like as just witnessed in your last message): exactly this is and was not acceptable for me. that code was almost exactly what I've been told after the second approach (the mail you quoted over there). I've been told to not do it like that at the beginning after I submitted the first code and finally after wasting weeks of rewriting and rebasing more code on that I'm getting told to move the code back where it was at the very first beginning? Back then I moreover had the feeling I'm getting pushed around by clueless people (and it definitelly was like that), everyone dreamed about his own ideas. This is the reason why relying on linuxtv is very bad. Sometimes clueless people try to guide people who are looking for a solution, although the people who back then had no clue at the beginning also improved their knowledge as everyone did. a) So support for the xc3028 etc etc stuff wasn't added at the beginning of the summer because someone had made a mistake and, instead of accepting that at face value, you deemed the entire situation completely unacceptable, left LinuxTV, and proceeded to make the same group of end users (whose sympathies you keep angling towards) wait several months more for a general solution? That sounds significantly different from what you stated earlier: The reason is that the linuxtv project depends on people who have their own ideas and do not care about other solutions or temporary solutions to get things done, or (vindictively) here: http://mcentral.de/pipermail/em28xx/2007-August/000646.html) Are you sure that you're earlier comment shouldn't have been: The reason is that the xc3028 etc depended upon Markus who had his own ideas and did not care about other solutions or temporary solutions to get things done. b) The inefficiencies that you have described above are rampant in corporate environments. Only there, when you pick up your ball and go home because circumstances no longer suit your fancy you no longer get that paycheck. I still have logs where I asked those people if there's any solution available logs from the very first beginning where everything was peaceful. Then call them out on this. Name names. Bring some closure to this. Harbouring resentments isn't going to resolve anything. Neither is continually stating something along the lines of oh, its history, lets not discuss this any more and then go turning around to call people clueless, etc etc at the next opportunity that avails itself to you. Obviously its not over for you, or you'd let it go. Bring it out in the open -- no private message, no personal emails. Let everyone have access to the same discussion. Air your complaints. This is the reason why relying on linuxtv is very bad The userspace tuners allows developers to add tuners independently of linuxtv and manage them by themself if they don't want to submit them officially, also it opens the possibility that people can do whatever _they_ want in userspace adding more features and taking the advantage of the userspace environment. It will avoid discussions with people who might misguide them (this also happened with me when I first tried to discuss some issues - I enjoyed Johannes statement once which was something like this would mean that the work gets manipulated). So, what exactly is good about LinuxTV? Everyone seems to be a real expert on what's shitty around here. So what's good? Feel free to continue this part in the other thread (which you created -- http://www.linuxtv.org/pipermail/linux-dvb/2007-August/019929.html --- which I agree is more suited for such conversation, and to leave this one for technical discussionalthough I must add that I hope that your please stop hijacking the userspace tuner thread remark applies equally to the supportive, yet non-technical comments you receive on your Userspace tuner. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Lock problems about mt2131
kevin liu wrote: No, I read the status register in tuner set parameters function, it seems locked. but my demod chip just can not detect any available signals. And I read the registers 0x01, 0x02,0x03,0x04, 0x05,0x06, Compare these values to these read through windows driver, these values are not correct So I suspect the algorithm provided in the mt2131 driver. de Can you help me with this problem? Besides, I am developing the au8502 driver, once it is completed, I think I will release Auvitek demodulator driver to the Linux kernel source. Thank you . Kevin. On 8/17/07, *Steven Toth* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: kevin liu wrote: Hi Steven I used FUSION HDTV5 USB silver tv card to test my environment, it is OK. And I used auvitek au8502 demodulator, with mt2131 as its tuner. I set au8502 to 8VSB mode, and I compile my mt2131.ko module from the lastest v4l-dvb tree, But the signal just can not be locked. How could I debug this problem, could you give me some advice? It the tuner locking? If you put debug messages in the get_status or equivalent function so yuo see the tuner register indicating lock? Is the auvitek au8502 demod driver doing to be an opensource driver? - Steve Hi, Please keep the linux-dvb mailing list CC'd at all times on this thread, and reply to all comments inline, not at the beginning of the email. Thanks. Can you publish a preliminary datasheet for the Demod, or a preliminary GPL driver for the demod yet? That might help. What I/F frequency does the demod need? I suspect the 2131 driver is fixed to match the demods it's been implemented against, and will probably need to have the I/F determined during dvb_attach in the mt2131_config structure. The MT2131 driver's pretty raw and support for new demods will grow over time, it can be easily extended to incorporate your demod's needs. - Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] add device node locking possibility todvbcore
Manu Abraham wrote: ts_bus_ctrl does a kind of reference counting. For readers: - fe-ops.ts_bus_ctrl(fe,1) is called during open - fe-ops.ts_bus_ctrl(fe,0) is called during close For the one and only writer: - fe-ops.ts_bus_ctrl(fe,1) is called during open - fe-ops.ts_bus_ctrl(fe,0) is called when the thread exits, usually after close So, how do you tell if the ts bus is already locked? I didn't want to write it but this is also what I would do, and I would also include the other dvb device nodes.. it doesn't make sense to keep them open as non functional dummies, or even allow people to open these nodes if the dvb mode is locked. What about a device with two frontends? Maybe the DVB-T/Analog frontend is locked by the V4L device, but you can still use a DVB-S frontend with dvb. In that case the demux could still be opened and used. This is what i stated multiple times: lock the device bus. It is a device property of a device with a single bus and 2 frontends. (A device driver represents the Hardware configuration, you are not making anything new/revolutionary here) Bus Locking wouldn't be necessary for a device with 2 frontends and 2 buses (ie 1:1 ratio, locking is required in cases other than this 1:1 case). That simple. But the general idea that carried forward was DVB core has to do the locking, rather than individual devices, which was conceptually wrong. Agreed. The drivers should expose their resources and the v4l / dvb core should abstract that and deal with resource allocation on the drivers behalf. Stee ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] add device node locking possibility to dvbcore
Hi Manu, Manu Abraham wrote: Andreas Oberritter wrote: I think that the option dvb_shutdown_timeout must be removed to fix the problem, where the frontend thread can be idle after close(). IMHO the thread should always be terminated when the last writer closes the device. The release function should then block until the thread really has terminated. Why would you need the frontend thread to be idle ? If you want the Sorry, I intended to write ... where the frontend thread can be *running* after close() ... I don't know, where my thoughts were at this time.. ;-) Regards, Andreas ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] saa7146_i2c_writeout: timed out waiting for end of xfer
On Tue, 2007-07-31 at 14:37 +0200, Oliver Endriss wrote: Stone wrote: On 7/17/07, Oliver Endriss [EMAIL PROTECTED] wrote: Oliver Endriss wrote: Imho the interrupt processing was broken: - The first I2C interrupt should be used to wake-up the task. It does not matter that it takes some time until ERR in IIC_STA will be updated. We don't need it. - Interrupts must be acknowledged at the end of the ISR. @all Please test the attached patch. There shouldn't be any unexpected I2C interrupts anymore. Attached is an updated patch which does extended status checking. Did this patch solve everyone's problems? Is is checked in now? There was little feedback, so it's not in the repository yet. I would really appreciate if more people would test this patch, no matter whether they have a problem with the current driver or not. It would reduce the risk to introduce a bug. I was now using this patch for 1-2 weeks. This setup has a FF-dvb-c and a budget dvb-t card and after the patch there were no more timeout messages. However since I added the asus p7131 I am seeing this message regularly again (44 times in the last 5 days). Thanks for investigating on this!! Soeren ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Updated GenPix USB driver
Committed, thanks. I will ask Mauro to pull it to main, soon. Patrick. On Sun, 5 Aug 2007, Alan Nisota wrote: I've been pretty lax with this, and there are now 4 different versions of the GENPIX USB adapter. The newest 'Skywalker' models are fully self-contained, and need no additional hardware to be used. A very reliable DVB-S card even without using any of the alternate modulatations (which this kernel module does not currently support) The following patch adds support for all 4 versions of the genpix adapter (www.genpix-electronics.com). Please apply, Sign-off: Alan Nisota [EMAIL PROTECTED] ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Typo fix in Nova-TD description
Committed, thanks.
Patrick.
--
Mail: [EMAIL PROTECTED]
WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/
On Wed, 1 Aug 2007, Darren Salt wrote:
Signed-off-by: Darren Salt [EMAIL PROTECTED]
diff -r ad9b95d2aac4 linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Wed Aug 01 00:45:13
2007 +0200
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Wed Aug 01 15:41:37
2007 +0100
@@ -944,7 +944,7 @@ struct dvb_usb_device_properties dib0700
{ dib0700_usb_id_table[12], NULL },
{ NULL },
},
- { Haupauge Nova-TD Stick/Elgato Eye-TV Diversity,
+ { Hauppauge Nova-TD Stick/Elgato Eye-TV Diversity,
{ dib0700_usb_id_table[13], NULL },
{ NULL },
},
--
| Darren Salt| linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT.
You will visit the Dung Pits of Glive soon.
___
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
Re: [linux-dvb] [PATCH] Add IR support for Nova-T Stick etc.
Committed, thanks.
Patrick.
On Wed, 1 Aug 2007, Darren Salt wrote:
k
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Working with my Nova-T Stick (70001) with remote control model A415.
Untested with other dib0700m/dib0700p devices.
Signed-off-by: Darren Salt [EMAIL PROTECTED]
diff -r ad9b95d2aac4 linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Wed Aug 01
00:45:13 2007 +0200
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Wed Aug 01
15:31:35 2007 +0100
@@ -887,7 +887,12 @@ struct dvb_usb_device_properties dib0700
{ dib0700_usb_id_table[8], NULL },
{ NULL },
}
- }
+ },
+
+ .rc_interval = DEFAULT_RC_INTERVAL,
+ .rc_key_map = dib0700_rc_keys,
+ .rc_key_map_size = ARRAY_SIZE(dib0700_rc_keys),
+ .rc_query = dib0700_rc_query
}, { DIB0700_DEFAULT_DEVICE_PROPERTIES,
.num_adapters = 2,
--
| Darren Salt| linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT.
Proceed with caution - twisted mind under construction.
___
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
Re: [linux-dvb] [PATCH] Trivial: repair mixed parm descs in dvb-usb-init.c
Committed, thanks.
Patrick.
On Wed, 15 Aug 2007, Michael Mauch wrote:
Hi,
modinfo dvb-usb shows incomplete/mixed parameter descriptions:
parm: force_pid_filter_usage:int
parm: disable_rc_polling:force all dvb-usb-devices to use a PID
filter, if any (default: 0). (int)
With the patch:
parm: force_pid_filter_usage:force all dvb-usb-devices to use a
PID filter, if any (default: 0). (int)
parm: disable_rc_polling:disable remote control polling (default:
0). (int)
Regards...
Michael
Repair modinfo parameter descriptions for force_pid_filter_usage and
disable_rc_polling.
Signed-off-by: Michael Mauch [EMAIL PROTECTED]
--- linux-2.6.22-gentoo-r2/drivers/media/dvb/dvb-usb/dvb-usb-init.c.orig
2007-08-04 23:51:41.0 +0200
+++ linux-2.6.22-gentoo-r2/drivers/media/dvb/dvb-usb/dvb-usb-init.c
2007-08-15 18:31:30.187557637 +0200
@@ -24,7 +24,7 @@ MODULE_PARM_DESC(disable_rc_polling, di
static int dvb_usb_force_pid_filter_usage;
module_param_named(force_pid_filter_usage, dvb_usb_force_pid_filter_usage,
int, 0444);
-MODULE_PARM_DESC(disable_rc_polling, force all dvb-usb-devices to use a PID
filter, if any (default: 0).);
+MODULE_PARM_DESC(force_pid_filter_usage, force all dvb-usb-devices to use a
PID filter, if any (default: 0).);
static int dvb_usb_adapter_init(struct dvb_usb_device *d)
{
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] bus control
My plan goes this way.
* dvb-usb provides the real I2C bus.
* the Host BIU is registered, which registers Virtual Bus #0 and #1
* the MASTER demod get's attached to VBus #0 - 0
* the MASTER tuner get's attached as a SLAVE on to the MASTER demod on
VBus #0 - 1
* the SLAVE demod get's attached to VBus #1
* the SLAVE tuner get's attached as a SLAVE on to the SLAVE demod on VBus #1
- 0
* firmware is downloaded via VBus #0 to the Host
After some efforts, i got to a stage where most things are done, except
for some small issues that i find a bit nasty.
Most of the nastiness can be seen in af901x_biu.c (i have added in the
comments near the relative areas)
The major issue that i face is that dvb-usb sees the Bus Interface as 2
objects (in the dual demod configuration), since there are 2 frontend's
being attached. (I don't see any clean way where i can do the BIU config
and or BIU specific access, which in fact happens only once)
Since i got a bit stuck up with frontend attach itself, temporarily left
out the firmware copy part.
Comments and thoughts would be interesting.
Thanks,
Manu
/*
AF-901x DVB-T demodulator driver
Copyright (c) Manu Abraham [EMAIL PROTECTED]
Copyright (c) AFA Technologies
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#ifndef __AF901x_PRIV_H
#define __AF901x_PRIV_H
/**
* For the USB devices, the i2c_adapter is just virtual
* but on the PCIe devices, it is in fact a real bus
*/
struct af901x_state {
struct i2c_adapter *i2c_adapter;
struct af901x_config*config;
enum fe_status stat;
u32 ber;
u32 unc;
u16 abort_count;
struct dvb_frontend frontend;
enum fe_modulation constellation;
u32 fcw;
u8 unplug_th;
};
#endif //__AF901x_PRIV_H
/*
AF-901x DVB-T demodulator driver
Copyright (c) Manu Abraham [EMAIL PROTECTED]
Copyright (c) AFA Technologies
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#ifndef __AF9015_H
#define __AF9015_H
#include linux/dvb/frontend.h
#define AF9015_DEFAULT_TS_PACKT_LEN 64
#define AF9015_DEFAULT_TS_FRAME_SIZE(64 * 188)
enum af901x_ts_mode {
AF901x_MPEG_PARALLEL= 0,
AF901x_MPEG_SERIAL,
AF901x_USB,
};
enum af901x_f_sample {
AF901x_FSAMPLE_28800= 28800, /* 28.800 MHz */
AF901x_FSAMPLE_20480= 20480, /* 20.480 MHz */
AF901x_FSAMPLE_28000= 28000, /* 28.000 MHz */
AF901x_FSAMPLE_25000= 25000, /* 25.000 MHz */
};
struct af901x_config {
u8 addr;
u8 slave;
u8 eeprom_addr;
u8 tuner_addr;
// interface setting
u32 frame_size;
u16 packt_size;
/* Initial settings*/
enum fe_bandwidth bandwidth;
u32 inversion; // convert to enum
enum af901x_ts_mode ts_mode;
enum af901x_f_samplef_sample; /* nyquist sampling */
u32 i_freq_0; /* IF 1 */
u32 i_freq_1; /* IF 2 */
// u32 osc_freq; /* OSC freq = nyquist freq */
};
#endif //__AF9015_H
/*
AF-9015 Bus Interface Unit driver
Copyright (c) Manu Abraham [EMAIL PROTECTED]
Copyright (c) AFA Technologies
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
[linux-dvb] [RFC] Hybrid tuner refactoring, phase 1
For the past few months, I've been working on refactoring the analog tuner.ko module, such that all hardware-specific code can be separated into dvb_frontend style tuner modules. This allows for a single module to be used by both the v4l2 tuner interface via the tuner.ko i2c_client driver, and directly by the dvb subsystem's tuning system. This refactoring process has zero impact to the way that v4l and dvb functions. I have completed phase one of the refactoring process, and now it is ready for testing and review. http://linuxtv.org/hg/~mkrufky/tuner-refactor-phase-1 A brief description of the individual changesets follows: - tuner: kill i2c_client interface to tuner sub-drivers This changeset removes the i2c_client interface between tuner.ko and the tuner sub-drivers. The i2c_client interface to tuner.ko, itself, remains the same as it has been -- this is only an internal change that affects the interaction between tuner.ko and the hardware-specific code. Some helper functions and macros were added in this changeset, in order to ease the conversion process, without causing headaches or breakage. (see tuner-i2c.c) We can remove these extra structs and helper functions after the refactoring process is complete. - hybrid tuner refactoring core changes, phase 1 This changeset contains the more interesting work, where tuner-core is altered to support attachment of dvb_frontend style tuner modules. An additional method set_analog_params was added to struct dvb_tuner_ops, so as to avoid altering the DVB subsystem userspace API headers. This change does not create any dependency of the DVB subsystem on V4L, nor does it create any dependency of the V4L subsystem on DVB. - tda8290: convert from tuner sub-driver into dvb_frontend module - mt20xx: convert from tuner sub-driver into dvb_frontend module - tea5761: convert from tuner sub-driver into dvb_frontend module - tea5767: convert from tuner sub-driver into dvb_frontend module - tuner-simple: convert from tuner sub-driver into dvb_frontend module These changesets handle the conversions of the individual tuner sub-drivers into dvb_frontend style tuner modules. - tuner: alter Makefile to produce separate modules This changeset makes the changes to the build system, required for building the tuner sub-drivers as separate modules, and the ability to deselect undesired tuner sub-drivers via Kconfig. -- What comes next? After phase 1 of hybrid tuner refactoring is merged into the master branch, there is no change to the behavior of the drivers, apart from the fact that users will now have the ability to deselect undesired tuner sub-drivers via Kconfig. I have the following changes planned for hybrid tuner refactoring, phases 2, 3 and 4: - analog if demodulator refactoring In this step, an internal api for analog IF demods will be created, allowing us to refactor the tda9887 module, and also to handle tda8290 separately from the tda8275 and tda8275a tuners. - tda8290 refactoring In addition to the analog if demodulator refactoring, duplicated code for the tda8275 and tda8275a tuners between tda8290.ko and tda827x.ko shall be consolidated. In addition, support for the tda8295 and tda18271 devices will be added. - tuner-simple refactoring Tuner-simple will be cleaned up to take on more of an object-oriented approach, and duplicated code for certain tuners present in both tuner-simple and dvb-pll shall be consolidated. - miscellaneous work and additional cleanups mt20xx shall be cleaned up to properly handle tuning requests from the DVB subsystem, rather that going through tuner.ko -- this is a very small change, but I decided to wait on this until after phase 1 is merged into master. Support for new hybrid tuner hardware will now be _much_ easier to develop and add into the v4l-dvb codebase. -- I'd like to thank all of the people that have looked this over thus far, whom have given suggestions on how I can make this better and easier to review. If there are any other questions, comments or concerns, I would love to hear them. Please don't be shy -- feel free to let me know if you like or dislike this approach. I'd like to have this merged as soon as possible, so that I may continue to work on the items mentioned about in the What comes next? section. Now, it's time to go out and party! I will be able to respond to any comments tomorrow afternoon. Regards, Michael Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] FREECOM TNT USB Stick (25451)
On Thu, 16 Aug 2007, RENOUARD Jean-Patrick wrote: also, what is PID Filtering used to ? I've seen in the Freecom source code that DVB_USB_ADAP_HAS_PID_FILTER is used. Does that mean that the device suport USB1.1 ? That means it might work under USB 1.1, because it only passes on packets with the right PIDs meaning that the bandwidth required will probably fit into USB 1.1. Also on this link ( http://www.linuxtv.org/wiki/index.php/DVB-T_USB_Devices ), Freecom DVB-T USB Stick (25451 rev3) is marked as USB2.0 and not USB1.1 but the WT-220U chipset seens to be the same that in the others devices. This may not be the current Freecom DVB-T USB Stick though. I bought one in April 2006, and mine uses the ZL0353 chip which I believe is a later revision than the one you are considering. This only works on USB 2.0 unless I apply a kernel patch (which I posted to this list some time ago) because one of the data channels is isoc under USB 1.1 and bulk under USB 2.0. Michael Young ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] R: [PATCH to be tested] hvr3000 repository ported to todaysnapshot - support multiple frontends of hvr3000 and flydvbwithout rmmod/insmod
Hi, DVB-T: audio ok, no video DVB-S: frontend selected but no audio and no video yet Perhaps is a problem with channel file. I get the same problem with the original snapshot Eddi ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] saa7146_i2c_writeout: timed out waiting for end of xfer
André Weidemann wrote: Oliver Endriss wrote: Hi Oliver, Please try the current HG driver. (Important because timeouts are now logged in poll mode, too.) I downloaded the refactoring driver from the bz2-link on this page: http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-refactoring and compiled them. If it still happens, please replace SAA7146_USE_I2C_IRQ by SAA7146_I2C_SHORT_DELAY in av7110.c. Does it help? With the new driver I still got the error message :-(. But it looks slightly different than before: saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer. Yes, I slightly modified the messages. I presume the (1) is the second registered frontend. Correct. Well this is my budget-ci card and not the FF-Card... So I thought I might as well try your advice for the FF card for the budget card and changed the flag in budget-ci.c to SAA7146_I2C_SHORT_DELAY. Now the error message that shows is: saa7146_i2c_writeout [poll]: timed out waiting for end of xfer Thanks. It shows that disabling IRQ mode does not solve the problem. Note that older drivers did not log this message in POLL mode, but the underlying problem was always was there. Until now I thought that the motherboard change had caused this problem, but at the same I have replace the S1400 with an S1500 with a CI connected to it. I now have an Asus M2NPV-VM(NVidia GeForce 6150 + nForce 430) with an Athlon64 3200+ and 512MB DDR2 RAM(667). I am running Debian Etch x86_64 with kernel 2.6.20+refactoring driver. Maybe some of the above might give you a clue on what could be the cause of the problem. Thank you for looking into the problem. Unfortunately, I have no idea why the I2C transfer hangs sometimes. Is there any pattern? Does it happen rarely or does the message flood your logs? If it does not happen too often, it should not be a big problem, because the I2C transfer will be retried... CU Oliver -- VDR Remote Plugin 0.3.9: 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
Re: [linux-dvb] System load raises when budget_av is loaded
[EMAIL PROTECTED] wrote: 2007/8/18, e9hack [EMAIL PROTECTED]: I've modified saa7146_wait_for_debi_done() a little bit. The function returns earlier from the second loop, if nobusyloop was 0 and if SPCI_DEBI_E was set after 100usec. I've used udelay() and an additional counter. My TT-C2300 has reported an ARM boot error. The unmodified driver wasn't able to restart the ARM. I must do a power off to recover the TT-C2300. I will do more test on this issue, but currently I do some tests on a TT-C1500. Too many challenges are not so good at the same time. It seems, the delay of 100usec is too short. During booting of the ARM, DEBI_E is set for ca. 360usec after some debi commands. I've changed the delay to 500usec. The load average is dropped from 0.65 to 0.0 with budget_av and dvb_ttpci loaded and vdr isn't running. With this patch I get random error messages from av7110_debiread|write: | Aug 19 01:26:05 orion kernel: av7110_debiread: wait_for_debi_done #1 failed | Aug 19 01:26:05 orion kernel: av7110_debiwrite: wait_for_debi_done failed Oliver -- VDR Remote Plugin 0.3.9: 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
Re: [linux-dvb] saa7146_i2c_writeout: timed out waiting for end of xfer
Oliver Endriss wrote: Unfortunately, I have no idea why the I2C transfer hangs sometimes. Is there any pattern? Does it happen rarely or does the message flood your logs? Within 2h 30min(VDR's last uptime) the poll timeout occurred 131 times. So the average occurrence is less than once a minute. It only happened once, that there were two log entries with the same system time. Between all the other logs are 3 seconds to a few minutes. Sometimes the timeouts occur in pairs. Meaning, there are only a few seconds between two log entries. The then following message is usually ~20 seconds to a few minutes later. If it does not happen too often, it should not be a big problem, because the I2C transfer will be retried... I guess I'm fine here since the system seems to be running flawlessly, nevertheless. André ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] add device node locking possibility to dvbcore
Steven Toth wrote: Trent Piepho wrote: On Fri, 17 Aug 2007, Markus Rechberger wrote: as I wrote earlier the thread can be idle/closed even before the node gets closed (you can test that with kaffeine, and you can test the other case with the scan utility) How can this happen? Afaics the fe thread may continue to exist after the device node was closed, but not vice-versa. Yes, how can that happen? What will make the dvb frontend thread exit before the device is closed? I don't know. I should probably spend sometime reminding myself of the purpose of the thread. It cannot happen, unless someone kills the thread... Maybe it would be a good idea to do what Andreas suggested and have the frontend release function block until the frontend thread has exited. AFAIK, the thread hanging around after the device is closed does nothing but cause problems. It's a very common FAQ, Q: Why does it mythtv not work if I change from a digital channel to an analog one? A: You need to set dvb_shutdown_timeout to 0. What's the purpose of dvb_shutdown_timeout 0? Does anyone know, why dvb_shutdown_timeout was introduced initially? I don't have a problem if it will be removed, but I suspect there was a reason for it. Anyway, we should set the default to 0. We should be clear that the ts_bus_ctrl isn't design to lock or version count in any way. The purpose of the callback is to allow the bridge to determine whether the it has sufficient hardware resources to allow the ops open to complete (assuming that the callers wants data). The best example of this todate has been the HVR1300 sub-drivers in which a V4L and DVB ops structures both need to access frontends on the single PCI bus. Ok, then it is probably used the wrong way in dvb_frontend.c. It should only be called for - the first open of the fe device and - the last close of the fe device (or maybe when the frontend thread exits, whichever comes later). For multiple tuners ts_bus_ctrl is responsible to do the right thing. Having a DVB application interfere with the V4L application's use of the bus isn't acceptable. Personally, I think ts_bus_ctrl needs to be replaced with a single resource allocation/deallocation mechanism that extends beyond simple bus negotiation into tuners, demods, encoders and other devices. ts_bus_ctrl does a kind of reference counting. For readers: - fe-ops.ts_bus_ctrl(fe,1) is called during open - fe-ops.ts_bus_ctrl(fe,0) is called during close For the one and only writer: - fe-ops.ts_bus_ctrl(fe,1) is called during open - fe-ops.ts_bus_ctrl(fe,0) is called when the thread exits, usually after close So, how do you tell if the ts bus is already locked? Until now it's never been a requirement. Simply try to lock it. If it fails, you know that it is taken. ;-) I didn't want to write it but this is also what I would do, and I would also include the other dvb device nodes.. it doesn't make sense to keep them open as non functional dummies, or even allow people to open these nodes if the dvb mode is locked. What about a device with two frontends? Maybe the DVB-T/Analog frontend is locked by the V4L device, but you can still use a DVB-S frontend with dvb. In that case the demux could still be opened and used. The HVR1300 (and HVR3000 / 4000) prohibit this by using ts_bus_ctrl, these are good examples. Btw, someone reported at vdr-portal, that cx88_dvb does not allow the frontend to be opened more than once anymore. Seems to be caused by calling the ts_bus_ctrl hook in dvb_frontend. Note that it should always be possible to open the fe for additional readers. femon can be run concurrently, for example. CU Oliver -- VDR Remote Plugin 0.3.9: 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
Re: [linux-dvb] saa7146_i2c_writeout: timed out waiting for end of xfer
Am Samstag, den 18.08.2007, 22:53 +0200 schrieb Soeren Sonnenburg: On Tue, 2007-07-31 at 14:37 +0200, Oliver Endriss wrote: Stone wrote: On 7/17/07, Oliver Endriss [EMAIL PROTECTED] wrote: Oliver Endriss wrote: Imho the interrupt processing was broken: - The first I2C interrupt should be used to wake-up the task. It does not matter that it takes some time until ERR in IIC_STA will be updated. We don't need it. - Interrupts must be acknowledged at the end of the ISR. @all Please test the attached patch. There shouldn't be any unexpected I2C interrupts anymore. Attached is an updated patch which does extended status checking. Did this patch solve everyone's problems? Is is checked in now? There was little feedback, so it's not in the repository yet. I would really appreciate if more people would test this patch, no matter whether they have a problem with the current driver or not. It would reduce the risk to introduce a bug. I was now using this patch for 1-2 weeks. This setup has a FF-dvb-c and a budget dvb-t card and after the patch there were no more timeout messages. However since I added the asus p7131 I am seeing this message regularly again (44 times in the last 5 days). Thanks for investigating on this!! Soeren Soeren, i know this sounds extremely stupid. But make sure the cards have a relaxed seat in the slots. There is enough stuff out there, which does not even stay an antenna connector change at run time. It is not even related to the price of the housings, just missing precision in can art. Just to have it said. Cheers, Hermannn ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] add device node locking possibility to dvbcore
Oliver Endriss wrote: Does anyone know, why dvb_shutdown_timeout was introduced initially? It was originally introduced looong time back by Obi. Some operations still incomplete on close() was the reason stated, IIRC. It had something to do with the FF cards ?, dunno. I don't have a problem if it will be removed, but I suspect there was a reason for it. Anyway, we should set the default to 0. I think a lot of people have been using it as set to 0. Ah, well that includes myself. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
