Re: [linux-dvb] TDA10086 with Pinnacle 400e tuning broken
Hi, Hartmut Hackmann wrote: ... So here is the patch that make the the 22kHz tone a config option. Please be aware that i have no means to test it, so please report Signed-off-by: Hartmut Hackmann [EMAIL PROTECTED] Acked-by: Oliver Endriss [EMAIL PROTECTED] CU Oliver -- VDR Remote Plugin 0.4.0: 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] Technotrend TT-budget S1500 PCI card and the [EMAIL PROTECTED] software support.
CityK wrote: Michael Finch wrote: I was imply try to find out if anyone had a recommendation if I should use the S-1500 card than the S-1401... I was not complaing that there is no S-1401 support. Sorry to bother you. Date: Sun, 20 Jan 2008 17:16:58 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: Technotrend TT-budget S1500 PCI card and the [EMAIL PROTECTED] software support. Michael Finch wrote: I have noticed that there is significant support for the Technotrend TT-budget S1500 PCI card, which I am excited to see. My question is why is there no such support for the Technotrend TT-budget S1401 card. I have a client with a new project that requires using one of these cards (or something similar). Is the S1500 a better choice? Playing the role of the list ogre (yet again): a) you're asking on the wrong list. Your questions are in regard to two DVB-S cards whom have nothing to do with V4L ... try linux-dvb instead b) in regards to your question as to why is there no such support, I'll ask you to consider from where such support should be derived? Perhaps you are unaware that there aren't a whole lot of developers around who write drivers for v4l or dvb devices. So, perhaps the simpler answer/explanation is this: no developer with any interest in writing drivers for a device = no support for such device (which I suppose a real ogre would have eloquently worded as support doesn't magically materialise or grow on trees). I was not complaing that there is no S-1401 support. I never took it as a complaint. I took it at its face value -- a question as to why there is no support for the S-1401 I was imply try to find out if anyone had a recommendation if I should use the S-1500 card than the S-1401 If you already knew that the S1401 is unsupported, then surely you already knew the answer to that question, else you were seeking a rather one sided recommendation or otherwise... The DVB-S 1401 is supported: | $ grep 1401 *.c | budget.c: case 0x1018: // TT Budget-S-1401 (philips tda10086/philips tda8262) | budget.c:MAKE_BUDGET_INFO(ttbs1401, TT-Budget-S-1401 PCI, BUDGET_TT); | budget.c: MAKE_EXTENSION_PCI(ttbs1401, 0x13c2, 0x1018), Simply use the budget driver. CU Oliver -- VDR Remote Plugin 0.4.0: 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] Diseqc and TT 3200-S2
Manu Abraham wrote: Marco Coli wrote: Remy Bohmer ha scritto: Hello Marco, Can you please post the results of lspci -v concerning your card? Maybe mine has something different. Thank you. My lspci -v follows: 04:07.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Unknown device 5b2f:1081 Flags: bus master, medium devsel, latency 32, IRQ 5 Memory at fddfe000 (32-bit, non-prefetchable) [size=512] FYI: My TT- S2-3200 has subsystem ID: 13c2:1019 So, there really seems to be different boards under the same name out there... well well well, mistery revealed! For the developers: are you already aware of these differences? Do you need more info? Is support for this board planned? Well, it looks like you have a broken EEPROM. 0x13c2: 1019 is the ID for the TT S2 3200 and Skystar DVB-S2 H Dcards that i have known. Oliver has an EEPROM rewriting application somewhere. I remember him talking about it sometime back. Alternatively you can search the archives, for fixing the EEPROM. (Added CC to Oliver. Maybe he can give you more explanations) Hm, 5b2f:1081 does not look like a typical overwritten subsystem id. Usually you see byte combinations with a0/a1/ff. Strange. Anyway, you can download the tool from http://escape-edv.de/endriss/dvb/fix_eeprom.c Please follow the instructions at the beginning of the file. CU Oliver -- VDR Remote Plugin 0.4.0: 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] [Review] Multiproto tree
Manu Abraham wrote:
Oliver Endriss wrote:
Card drivers (budget-ci, budget-av)
---
I didn't check the details, but the extensions look ok.
You might consider whether parts of the stb0899/stb6100 stuff could be
factored out into a header file. See bsru6.h for an example.
It would reduce the file size, and tables etc could be reused.
I did visit this, but there result looked thus, the device is not specific to
a tuner
as it is, and in each of the card configurations, the tables do have some
changes
It depends on the card manufacturer.
Thinking thus, i thought of moving all the tables to a header where,
something
such as stb0899_config.h where all the card specific tables are thrown in.
This
doesn't reduce any of the compiled object size, but it does bring in the
advantage
that budget_ci.c, budget_av.c are not cluttered with large tables.
What do you think of moving all the config's to a public config file ?
Fine. Imho we should focus on maintainability, not on object size.
Maintainer's time is the most valuable ressource. Having the configs in
a central file makes it easier to reuse the tables and to keep them
in-sync.
Otherwise someone would probably just copy/paste the stuff for a new
driver, as it was done in the ttpci driver family. There are tons of
config tables which should be cleaned up and (possibly) merged.
Due to lack of hardware and/or testers this is nearly impossible now
without risking to break a driver... :-(
+ /* Legacy */
+ if (fe-legacy) {
+ if (fe-ops.set_frontend)
+ fe-ops.set_frontend(fe, fepriv-parameters);
+ } else {
+// if ((dvbfe_sanity_check(fe) == 0)) {
+ /* Superseding */
+ if (fe-ops.set_params)
+ fe-ops.set_params(fe, fepriv-fe_params);
+// } else
+// return -EINVAL;
+ }
Sanity checks should be done in FE_SET_FRONTEND/DVBFE_SET_PARAMS ioctls.
(See HG master where I added this some time ago.)
Otherwise the application would not see an error status.
Since you already have a check, i guess i can drop the dvbfe_sanity_check()
Yep. Feel free to add more checks to dvb_frontend_check_parameters().
Atm it only checks the limits of frequency and symbol rate.
/* don't actually do anything if we're in the LOSTLOCK state,
-* the frontend is set to FE_CAN_RECOVER, and the max_drift is 0 */
- if ((fepriv-state FESTATE_LOSTLOCK)
- (fe-ops.info.caps FE_CAN_RECOVER) (fepriv-max_drift ==
0)) {
- dvb_frontend_swzigzag_update_delay(fepriv, s FE_HAS_LOCK);
- return;
+* the frontend is set to FE_CAN_RECOVER, and the max_drift is 0
+*/
+ /* Legacy */
+ if (fe-legacy) {
+ if ((fepriv-state FESTATE_LOSTLOCK)
(fepriv-max_drift == 0)) {
+ if (fe-ops.get_frontend_algo)
+ if (fe-ops.get_frontend_algo(fe) ==
DVBFE_ALGO_RECOVERY)
+
dvb_frontend_swzigzag_update_delay(fepriv, s FE_HAS_LOCK);
+
+ return 0;
+ }
+ } else {
+ if (fepriv-state FESTATE_LOSTLOCK) {
+ if (fe-ops.get_frontend_algo) {
+ if ((fe-ops.get_frontend_algo(fe) ==
DVBFE_ALGO_RECOVERY)
+ (fepriv-max_drift == 0)) {
+
+
dvb_frontend_swzigzag_update_delay(fepriv, s DVBFE_HAS_LOCK);
+ return 0;
+ }
+ }
+ }
}
The 'if (fe-legacy)' branch looks broken:
fe-ops.get_frontend_algo is most likely zero, so
dvb_frontend_swzigzag_update_delay will not be called for old drivers.
This one's fixed although i see no usage of FE_CAN_RECOVER which is used in
the
tree currently, rather than bogus usage
Finally, I did a quick test with this tree, and it worked. ;-)
- dvb-ttpci driver with DVB-S Rev 1.3 (ves1x93)
- budget driver with DVB-S Nova Rev 1.0 (stv0299)
- VDR (using old API)
Marco pointed to another bug a wrong copy, which breaks backward compatibility
for DVBFE_GET_PARAMS
Any further issues that you see ?
No.
Additionally i did work upon the Multiple TS stuff, haven't got it working
yet.
The concept works like this, unlike what we thought would be:
Manu,
The filtering is just like an IP address and subnet mask.
ISI_ENTRY equivalent to IP address.
IS_BIT_EN equivalent to subnet mask.
The incoming Bbheaders are compared to ISI_ENTRY through mask IS_BIT_EN.
Those Bbheaders that pass the test are allowed through to the TS. Those
that do
Re: [linux-dvb] Kernel module crash (divide error)
Rutger ter Borg wrote: Dear Linux DVB developers, I've been trying to get DVB-C working on my system, meanwhile with multiple DVB-C cards (KNC1 and Technotrend budget cards), with their CI counterparts, and Alphacrypt CAM, so far unfortunately without success. In my trial-and-error path I've encountered a possible bug in the linuxtv dvb-drivers. Apparently, it's possible to get accepted by the kernel a symbol rate of zero, causing a divide by zero error. This is valid for (Debian) kernels 2.6.18-4, 2.6.22-3, and 2.6.23-1. $ dvbstream -f 38800 -s 0 -o test.mpg This bug has already been fixed in the HG repository some time ago. The fix will be included in 2.6.24. CU Oliver -- VDR Remote Plugin 0.4.0: 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] CAM inserted/used reduces signal and SNR ?
Luc Brosens wrote: Hi, side note : the problems in my previous post KNC1 TV-Station S, revision 0x1894, doesn't tune, were related to the PCI-slots of the motherboard I used rebuilt the machine around a new motherboard, both KNC1's are now recognized and able to tune lesson learnt : check the hardware before complaining about the software ... Hm. why does inserting and accessing a CAM reduce the signal and SNR levels ? (even if no descrambling is needed, as for BBC World) how can this be solved ? anyone out there having the same problems ? I guess that the CAM increases the noise on the power supply planes of the card. This might affect the tuner. ;-( CU Oliver -- VDR Remote Plugin 0.4.0: 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] [Review] Multiproto tree
Manu Abraham wrote:
Oliver Endriss wrote:
...
For now I ignored all differences, except for:
- frontend.h
- dvb_frontend.[ch]
- budget-ci.c
- budget-av.c
API extensions (frontend.h)
---
looks fine
Card drivers (budget-ci, budget-av)
---
I didn't check the details, but the extensions look ok.
You might consider whether parts of the stb0899/stb6100 stuff could be
factored out into a header file. See bsru6.h for an example.
It would reduce the file size, and tables etc could be reused.
The tables in some cases can't be reused, but the functions can be, due to
the initial cut and paste (tables), both set of tables have some amount of
common factor, But still in the end there will be a large common factor
altogether.
Ok, It does make sense to move it out to a common header.
If there are only minor differences, some settings could be moved to the
xxx_config struct. A different approach might use #ifdef blocks within
the header file. One could easily select a configuration by doing
#define xxx_CONFIG_A
#include xxx.h
dvb-core: dvb_frontend.c
fe-legacy is turned on/off by various ioctls:
- FE_SET_FRONTEND, FE_GET_FRONTEND - 1
- DVBFE_SET_PARAMS - 0/1
- DVBFE_GET_PARAMS, DVBFE_GET_DELSYS, DVBFE_GET_INFO - 0
fe-legacy controls how the frontend thread works.
Since the frontend device can be accessed by multiple readers,
fe-legacy might be toggled in funny ways.
This might confuse the fe thread or dvb_frontend_add_event. ;-(
Imho ioctls should not set fe-legacy. All parameter conversions should
be done within the ioctl. For example:
- new driver: FE_SET_FRONTEND converts parms to new driver API
- old driver: DVBFE_SET_PARAMS converts parms to old driver API
Then the fe thread can simply use the old driver interface
(fe-legacy==1) or the new one (fe-legacy==0).
What's your thought, if i just checked for the new callbacks and handled the
legacy switch, ie: the check occuring in the init, so on an fe_open() the
legacy switch will be set, depending upon the driver. That way things would
be set just before the thread is started and still be independent of any
ioctl
handling, thereby avoiding the flip-flop case with an ioctl.
What do you think ?
Doing this in dvb_register_frontend() seems to be the perfect place,
because all callbacks have been set, and fe device/thread do not exist
yet.
The error msg should display the offending parameter:
Instead of
+ printk(%s: Unsupported FEC\n, __func__);
you might use
+ printk(KERN_ERR %s: Unsupported FEC %x\n, __func__,
new_fec);
(same way for other conversion routines)
Ok, fine. Better in fact.
+ /* Legacy */
+ if (fe-legacy) {
+ if (fe-ops.set_frontend)
+ fe-ops.set_frontend(fe, fepriv-parameters);
+ } else {
+// if ((dvbfe_sanity_check(fe) == 0)) {
+ /* Superseding */
+ if (fe-ops.set_params)
+ fe-ops.set_params(fe, fepriv-fe_params);
+// } else
+// return -EINVAL;
+ }
Sanity checks should be done in FE_SET_FRONTEND/DVBFE_SET_PARAMS ioctls.
(See HG master where I added this some time ago.)
Otherwise the application would not see an error status.
True, didn't think about returning the error back to the app. Will fix.
/* don't actually do anything if we're in the LOSTLOCK state,
-* the frontend is set to FE_CAN_RECOVER, and the max_drift is 0 */
- if ((fepriv-state FESTATE_LOSTLOCK)
- (fe-ops.info.caps FE_CAN_RECOVER) (fepriv-max_drift ==
0)) {
- dvb_frontend_swzigzag_update_delay(fepriv, s FE_HAS_LOCK);
- return;
+* the frontend is set to FE_CAN_RECOVER, and the max_drift is 0
+*/
+ /* Legacy */
+ if (fe-legacy) {
+ if ((fepriv-state FESTATE_LOSTLOCK)
(fepriv-max_drift == 0)) {
+ if (fe-ops.get_frontend_algo)
+ if (fe-ops.get_frontend_algo(fe) ==
DVBFE_ALGO_RECOVERY)
+
dvb_frontend_swzigzag_update_delay(fepriv, s FE_HAS_LOCK);
+
+ return 0;
+ }
+ } else {
+ if (fepriv-state FESTATE_LOSTLOCK) {
+ if (fe-ops.get_frontend_algo) {
+ if ((fe-ops.get_frontend_algo(fe) ==
DVBFE_ALGO_RECOVERY)
+ (fepriv-max_drift == 0)) {
+
+
dvb_frontend_swzigzag_update_delay(fepriv, s DVBFE_HAS_LOCK);
+ return 0
[linux-dvb] [Review] Multiproto tree (was: Re: Future of Multiproto)
Hi,
now we had bad weather, and I had some time to review the code. ;-)
General note
Obviously, the multiproto tree has not been updated from master for a
very long time. When merging care must be taken that no regressions flow
back to the main development tree.
For now I ignored all differences, except for:
- frontend.h
- dvb_frontend.[ch]
- budget-ci.c
- budget-av.c
API extensions (frontend.h)
---
looks fine
Card drivers (budget-ci, budget-av)
---
I didn't check the details, but the extensions look ok.
You might consider whether parts of the stb0899/stb6100 stuff could be
factored out into a header file. See bsru6.h for an example.
It would reduce the file size, and tables etc could be reused.
dvb-core: dvb_frontend.c
fe-legacy is turned on/off by various ioctls:
- FE_SET_FRONTEND, FE_GET_FRONTEND - 1
- DVBFE_SET_PARAMS - 0/1
- DVBFE_GET_PARAMS, DVBFE_GET_DELSYS, DVBFE_GET_INFO - 0
fe-legacy controls how the frontend thread works.
Since the frontend device can be accessed by multiple readers,
fe-legacy might be toggled in funny ways.
This might confuse the fe thread or dvb_frontend_add_event. ;-(
Imho ioctls should not set fe-legacy. All parameter conversions should
be done within the ioctl. For example:
- new driver: FE_SET_FRONTEND converts parms to new driver API
- old driver: DVBFE_SET_PARAMS converts parms to old driver API
Then the fe thread can simply use the old driver interface
(fe-legacy==1) or the new one (fe-legacy==0).
The error msg should display the offending parameter:
Instead of
+ printk(%s: Unsupported FEC\n, __func__);
you might use
+ printk(KERN_ERR %s: Unsupported FEC %x\n, __func__, new_fec);
(same way for other conversion routines)
+ /* Legacy */
+ if (fe-legacy) {
+ if (fe-ops.set_frontend)
+ fe-ops.set_frontend(fe, fepriv-parameters);
+ } else {
+// if ((dvbfe_sanity_check(fe) == 0)) {
+ /* Superseding */
+ if (fe-ops.set_params)
+ fe-ops.set_params(fe, fepriv-fe_params);
+// } else
+// return -EINVAL;
+ }
Sanity checks should be done in FE_SET_FRONTEND/DVBFE_SET_PARAMS ioctls.
(See HG master where I added this some time ago.)
Otherwise the application would not see an error status.
/* don't actually do anything if we're in the LOSTLOCK state,
-* the frontend is set to FE_CAN_RECOVER, and the max_drift is 0 */
- if ((fepriv-state FESTATE_LOSTLOCK)
- (fe-ops.info.caps FE_CAN_RECOVER) (fepriv-max_drift == 0)) {
- dvb_frontend_swzigzag_update_delay(fepriv, s FE_HAS_LOCK);
- return;
+* the frontend is set to FE_CAN_RECOVER, and the max_drift is 0
+*/
+ /* Legacy */
+ if (fe-legacy) {
+ if ((fepriv-state FESTATE_LOSTLOCK) (fepriv-max_drift ==
0)) {
+ if (fe-ops.get_frontend_algo)
+ if (fe-ops.get_frontend_algo(fe) ==
DVBFE_ALGO_RECOVERY)
+
dvb_frontend_swzigzag_update_delay(fepriv, s FE_HAS_LOCK);
+
+ return 0;
+ }
+ } else {
+ if (fepriv-state FESTATE_LOSTLOCK) {
+ if (fe-ops.get_frontend_algo) {
+ if ((fe-ops.get_frontend_algo(fe) ==
DVBFE_ALGO_RECOVERY)
+ (fepriv-max_drift == 0)) {
+
+
dvb_frontend_swzigzag_update_delay(fepriv, s DVBFE_HAS_LOCK);
+ return 0;
+ }
+ }
+ }
}
The 'if (fe-legacy)' branch looks broken:
fe-ops.get_frontend_algo is most likely zero, so
dvb_frontend_swzigzag_update_delay will not be called for old drivers.
Finally, I did a quick test with this tree, and it worked. ;-)
- dvb-ttpci driver with DVB-S Rev 1.3 (ves1x93)
- budget driver with DVB-S Nova Rev 1.0 (stv0299)
- VDR (using old API)
CU
Oliver
--
VDR Remote Plugin 0.4.0: 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] Problems with Terratec Cinergy 1200 DVB-T (tda10046_attach())
Oliver Haag wrote: Hi, I've bought the Terratec Cinergy 1200 DVB-T and have problems to get it running. I'm using Kubuntu Gutsy (amd64) with the 2.6.23.1 vanilla kernel (The official kernel in the repos is very very buggy, so I don't want to try it out there). Tried adding the modules in menuconfig and building them as described here http://www.linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers too. I always get the same error in dmesg: saa7146: register extension 'budget_av'. ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 18 ACPI: PCI Interrupt :01:00.0[A] - Link [LNKA] - GSI 18 (level, low) - IRQ 18 saa7146: found saa7146 @ mem c2aaec00 (revision 1, irq 18) (0x153b,0x115 7). saa7146 (0): dma buffer size 192512 DVB: registering new adapter (Terratec Cinergy 1200 DVB-T) adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:f f:ff:ff bttv: driver version 0.9.17 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture nvidia: module license 'NVIDIA' taints kernel. KNC1-0: MAC addr = 00:0a:ac:01:e7:02 DVB: Unable to find symbol tda10046_attach() This is the problem. See below. budget-av: A frontend driver was not found for device 1131/7146 subsystem 153b/1157 budget-av: ci interface initialised. It looks like the tda1004x-module is missing, but it isn't. It's also loaded: Module Size Used by tda1004x 16900 0 lp 11912 0 budget_av 21120 0 saa7146_vv 46912 1 budget_av videobuf_dma_sg13444 2 bttv,saa7146_vv videobuf_core 17028 3 bttv,saa7146_vv,videobuf_dma_sg budget_core11524 1 budget_av dvb_core 76116 2 budget_av,budget_core videodev 27456 2 bttv,saa7146_vv v4l2_common19968 4 bttv,compat_ioctl32,saa7146_vv,videodev v4l1_compat13316 3 bttv,saa7146_vv,videodev saa714617480 3 budget_av,saa7146_vv,budget_core ttpci_eeprom4352 1 budget_core The frontend device-node is missing, everything else is there: $ ls /dev/dvb/adapter0/ ca0 demux0 dvr0 net0 Also installed WinXP to try it out there and it's working fine, so it's no hardware-problem. Is this a bug (probably only on amd64 kernels) or am I just too stupid and did forget something? Please make sure that you do not mix modules from the kernel with modules from the v4l tree. This may cause all kind of problems. First unload all modules, then insmod tda1004x and the other modules from the v4l directory. CU Oliver -- VDR Remote Plugin 0.4.0: 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] KNC1 TV-Station S, revision 0x1894, doesn't tune
Luc Brosens wrote:
hello,
I've just put two of these card in my machine, and seem to run into the tuner
issue described at
http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_1200_DVB-S_budget/Typhoon/KNC1_DVB-S_budget
has anybody gotten these cards to work ?
any pointers on how to get tuning to work ?
I'm new to dvb-driver development, suggestions on how to get started are
welcome too
below are lspci output, dmesg output and scan output :
DMESG
saa7146: register extension 'budget_av'.
PCI: Setting latency timer of device :00:10.1 to 64
ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
ACPI: PCI Interrupt :04:08.0[A] - Link [APC1] - GSI 16 (level, low) -
IRQ 16
saa7146: found saa7146 @ mem c20010606000 (revision 1, irq 16)
(0x1894,0x0016).
saa7146 (0): dma buffer size 192512
DVB: registering new adapter (KNC TV STAR DVB-S)
adapter failed MAC signature check
encoded MAC from EEPROM was
ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff
KNC1-0: MAC addr = 00:09:d6:65:9d:14
DVB: registering frontend 0 (ST STV0299 DVB-S)...
budget-av: ci interface initialised.
The initialisation of the first card looks ok.
ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
ACPI: PCI Interrupt :04:09.0[A] - Link [APC2] - GSI 17 (level, low) -
IRQ 17
saa7146: found saa7146 @ mem c2001061c000 (revision 1, irq 17)
(0x1894,0x0016).
saa7146 (1): dma buffer size 192512
DVB: registering new adapter (KNC TV STAR DVB-S)
saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
Couldn't read from EEPROM: not there?
saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
KNC1-1: Could not read MAC from KNC1 card
DVB: registering frontend 1 (ST STV0299 DVB-S)...
budget-av: ci interface initialised.
budget-av: cam inserted B
saa7146: register extension 'dvb'.
dvb_ca adaptor 1: PC card did not respond :(
not all of these messages seem positive, should I worry ?
Yes. The second card does not work properly (I2C bus errors).
SCAN
silverstar:/home/myth # scan -vvv -a 1 /usr/share/dvb/dvb-s/Astra-19.2E
scanning /usr/share/dvb/dvb-s/Astra-19.2E
using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0'
initial transponder 12551500 V 2200 5
tune to: 12551:v:0:22000
DiSEqC: switch pos 0, 13V, hiband (index 2)
diseqc_send_msg:56: DiSEqC: e0 10 38 f1 00 00
DVB-S IF freq is 1951500
tuning status == 0x02
tuning status == 0x02
tuning status == 0x03
tuning status == 0x02
tuning status == 0x03
tuning status == 0x02
tuning status == 0x02
tuning status == 0x02
tuning status == 0x02
tuning status == 0x02
WARNING: tuning failed!!!
tune to: 12551:v:0:22000 (tuning failed)
DiSEqC: switch pos 0, 13V, hiband (index 2)
diseqc_send_msg:56: DiSEqC: e0 10 38 f1 00 00
DVB-S IF freq is 1951500
tuning status == 0x02
tuning status == 0x02
tuning status == 0x02
tuning status == 0x02
tuning status == 0x02
tuning status == 0x01
tuning status == 0x01
tuning status == 0x02
tuning status == 0x02
tuning status == 0x02
WARNING: tuning failed!!!
ERROR: initial tuning failed
dumping lists (0 services)
Done.
scan works with the first card ('-a 0'), correct?
the signal from the satellite is fine, have been using a settop box for
several months
a Skystar 2 card in the same machine scanned successfully and gave access to
the FTA channels
I'm using OpenSUSE 10.3, kernel version 2.6.22.12, dvb archive 816f256c2973
(downloaded it yesterday)
Swap the cards.
- If the errors moves to saa7146(0), the card might be broken.
- If the errors still come from saa7146(1), try a different PCI slot.
(I2C errors might be caused by noise on power supply lines.)
CU
Oliver
--
VDR Remote Plugin 0.4.0: 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] Problems with Terratec Cinergy 1200 DVB-T (tda10046_attach())
Oliver Haag wrote: Hello, thanks for your answer. I haven't mixed them up, so this shouldn't be the problem. One time I compiled the kernel with the modules without adding any modules from v4l-dvb - not working. Next time I unloaded all modules from the kernel and loaded the ones from v4l-dvb, same thing. I've also tried compiling the kernel without any dvb-modules and adding the ones from v4l-dvb to keep it really clean and as expected - not working ;) Do you have any other idea what's going wrong here? Iirc there is a problem with older kernels and the symbol_request stuff. You could try to disable [ ] Load and attach frontend modules as needed and recompile the driver. Then you must load all frontend drivers referenced by the driver, not only the one which your card needs. CU Oliver -- VDR Remote Plugin 0.4.0: 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] TT Cynergy 1200 DVB-C Device 1176
Thomas Kaiser wrote: Hi I read this thread http://www.linuxtv.org/pipermail/linux-dvb/2007-February/015663.html but I can not figure out if this card is now supported by linux-dvb? Should be supported by the budget-av driver. Oliver -- VDR Remote Plugin 0.4.0: 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] stv0297: improvement for qam256 modulated channels
[EMAIL PROTECTED] wrote: 2007/10/28, e9hack [EMAIL PROTECTED]: I've seen two different values for the carrier offset on Windows XP for a TT-C2300. Registers 20/21h are programmed with 3c0a or 3ba4 (carrier offset 6763 or 6718). The value depends on the driver revision. On a TT-C1500, this value is 4000 (carrier offset 7209). It may be possible, that the value is calculated from some other values. I know, that the patch has no effect for some testers. This is the first report with a failure. So it isn't possible to add the patch. In my case, I've some channels in the UHF range with a poor signal strength. Without the patch, I got ber ~3500h and unc 10h. With the patch, I get ber ~b00h and unc 0. Sorry, 'carrier offset' should be 'initial demodulation frequency'. What shall we do with this patch? I think we cannot apply it right now. @e9hack: Could it be that the windows driver tries different settings, and uses the one with the lowest BER? (Some kind of zig-zag scan for this parameter.) CU Oliver -- VDR Remote Plugin 0.4.0: 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] [Patch] saa7146: 'wait_for_debi_done' fixes
Oliver Endriss wrote: @all users of saa7146-based cards (drivers: dvb-ttpci, budget, budget-ci, budget-av) Please test whether the attached patch has any negative effects. Two fixes for the 'saa7146_wait_for_debi_done' code: (a) Timeout did not work when the routine was called with interrupts disabled. (b) Reduce PCI I/O load caused by saa7146_wait_for_debi_done. Seems to be very important on fast machines! Based on a patch posted by [EMAIL PROTECTED] If nobody complains I will commit this patch next week. Patch has been committed with slight modifications. CU Oliver -- VDR Remote Plugin 0.4.0: 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] [Patch] tda10021: The ber counting must be reinitialized after reading of the values
e9hack wrote: Hi, the attached patch fixes the not working ber counting of the tda10021 frontend. - Hartmut Committed to HG. Thanks. CU Oliver -- VDR Remote Plugin 0.4.0: 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] [Patch] stv0297: The value of the signal strength depends on the configuration of the agc polarity.
e9hack wrote: Hi, the attached patch fixes the increasing of the signal strength value (higher value = higher signal strength) and scales the value to the range of 0... The charcteristic itself is wrong. To get proper values on a TT-C2300 in the range of 40..60% real signal strength, the values from the patch should be divide by two. The attached patch doesn't fix the characteristic. Committed to HG. Thanks. CU Oliver -- VDR Remote Plugin 0.4.0: 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] [Patch] ves1820: increase acquisition range for clock recovery
Oliver Endriss wrote: @all users of ves1820-based DVB-C cards (FF ttpci, budget), please test whether the attached patch has any adverse effects. (Tests @vdr-portal did not show any problems yet.) It changes the acquisition range for clock recovery from 120 ppm to 240ppm. Apparently, some cable providers in Germany are playing with their parameters, and the capture range of the ves1820 is too small to acquire a lock with the current setting... ;-( If nobody complains I will commit this patch next weekend. Committed to HG. CU Oliver -- VDR Remote Plugin 0.4.0: 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] [Patch] tda10021: The value of signal strength depends on the configuration of the agc polarity.
Oliver Endriss wrote: e9hack wrote: Hi, the attached patch fixes the increasing of the signal strength value (higher value = higher signal strength). If nobody objects I'll commit this patch. Committed to HG. Thanks. CU Oliver -- VDR Remote Plugin 0.4.0: 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] [v4l-dvb-maintainer] FWD: [Patch] saa7146/budget*/dvb-ttpci: Remove V4L1 dependencies
Mauro Carvalho Chehab wrote:
Hi Oliver and Marco,
The patch looked good to me.
Some comments:
IMO, instead of creating an emum for vidmode, I would instead just store
v4l2_std_id there.
if (std-id V4L2_STD_PAL) {
- av7110-vidmode = VIDEO_MODE_PAL;
+ av7110-vidmode = AV7110_VIDEO_MODE_PAL;
av7110_set_vidmode(av7110, av7110-vidmode);
}
else if (std-id V4L2_STD_NTSC) {
- av7110-vidmode = VIDEO_MODE_NTSC;
+ av7110-vidmode = AV7110_VIDEO_MODE_NTSC;
av7110_set_vidmode(av7110, av7110-vidmode);
}
Basically the enum is not required.
Everything works fine without replacing VIDEO_MODE_xxx by
AV7110_VIDEO_MODE_xxx. (VIDEO_MODE_xxx is defined in videodev.h.)
On the other hand, I like the enum because it defines the interface
between firmware and driver in a clean way. video_tuner-mode defines
should not be used here because anything except VIDEO_MODE_PAL or
VIDEO_MODE_NTSC are not valid for the firmware. In the future the enum
might be extended to display NTSC content on a PAL TV...
I dunno if av7110 does support PAL/60, PAL/M or PAL/N. I did a quick
look on a datasheet I found at the net for
av7110(http://www.cdaniel.de/download/AV711x_3_1.pdfs). It seems that
the only supported PAL ones are PAL/BDGHI. If this is true, the above
code is perfect.
It's ok. Currently we don't support those PAL standards in the firmware.
However, if the driver supports other PAL standards, the above code
won't work, since a few PAL standards are not marked as V4L2_STD PAL
[1]. If this the case, the above code is not correct.
[1] On V4L2, V4L2_STD_PAL means only PAL/BGDKHI. IMHO, this is one of
the weird things at V4L2 API.
To support also PAL/60, and PAL/MN, a better coding would be:
if (std-id V4L2_STD_SECAM) {
printk(KERN_ERR Secam is not supported\n);
else if (std-id V4L2_STD_NTSC) {
av7110-vidmode = AV7110_VIDEO_MODE_NTSC;
av7110_set_vidmode(av7110, av7110-vidmode);
} else {
av7110-vidmode = AV7110_VIDEO_MODE_PAL;
av7110_set_vidmode(av7110, av7110-vidmode);
}
Or to use V4L2_STD_525_60 (for 60 Hz standards) and V4L2_STD_625_50 (for
50 Hz standards).
Also, please review the patch with scripts/checkpatch.pl.
Will do so.
CU
Oliver
--
VDR Remote Plugin 0.4.0: 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] FWD: [Patch] saa7146/budget*/dvb-ttpci: Remove V4L1 dependencies
Hi,
Marco Schlüßler sent me 2 patches which remove the V4L1 dependencies
from these drivers. Works fine here.
Please test. If nobody complains the patches will be applied.
CU
Oliver
--
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
- remove wrong include linux/videodev.h
Signed-off-by: Marco Schluessler [EMAIL PROTECTED]
diff -bur v4l-dvb-7a6fab6d00a0_orig/linux/include/media/saa7146_vv.h v4l-dvb-7a6fab6d00a0/linux/include/media/saa7146_vv.h
--- v4l-dvb-7a6fab6d00a0_orig/linux/include/media/saa7146_vv.h 2007-10-15 21:24:20.0 +0200
+++ v4l-dvb-7a6fab6d00a0/linux/include/media/saa7146_vv.h 2007-10-15 21:24:31.0 +0200
@@ -1,7 +1,6 @@
#ifndef __SAA7146_VV__
#define __SAA7146_VV__
-#include linux/videodev.h
#include media/v4l2-common.h
#include media/saa7146.h
#include media/videobuf-dma-sg.h- remove v4l1 code
Signed-off-by: Marco Schluessler [EMAIL PROTECTED]
diff -bur v4l-dvb-7a6fab6d00a0_orig/linux/drivers/media/dvb/ttpci/Kconfig v4l-dvb-7a6fab6d00a0/linux/drivers/media/dvb/ttpci/Kconfig
--- v4l-dvb-7a6fab6d00a0_orig/linux/drivers/media/dvb/ttpci/Kconfig 2007-10-15 21:24:20.0 +0200
+++ v4l-dvb-7a6fab6d00a0/linux/drivers/media/dvb/ttpci/Kconfig 2007-10-15 21:34:51.0 +0200
@@ -1,6 +1,6 @@
config DVB_AV7110
tristate AV7110 cards
- depends on DVB_CORE PCI I2C VIDEO_V4L1
+ depends on DVB_CORE PCI I2C
select FW_LOADER if !DVB_AV7110_FIRMWARE
select VIDEO_SAA7146_VV
select DVB_VES1820 if !DVB_FE_CUSTOMISE
@@ -59,7 +59,7 @@
config DVB_BUDGET
tristate Budget cards
- depends on DVB_CORE PCI I2C VIDEO_V4L1
+ depends on DVB_CORE PCI I2C
select VIDEO_SAA7146
select DVB_STV0299 if !DVB_FE_CUSTOMISE
select DVB_VES1X93 if !DVB_FE_CUSTOMISE
@@ -84,7 +84,7 @@
config DVB_BUDGET_CI
tristate Budget cards with onboard CI connector
- depends on DVB_CORE PCI I2C VIDEO_V4L1
+ depends on DVB_CORE PCI I2C
select VIDEO_SAA7146
select DVB_STV0297 if !DVB_FE_CUSTOMISE
select DVB_STV0299 if !DVB_FE_CUSTOMISE
@@ -106,7 +106,7 @@
config DVB_BUDGET_AV
tristate Budget cards with analog video inputs
- depends on DVB_CORE PCI I2C VIDEO_V4L1
+ depends on DVB_CORE PCI I2C
select VIDEO_SAA7146_VV
select DVB_PLL if !DVB_FE_CUSTOMISE
select DVB_STV0299 if !DVB_FE_CUSTOMISE
@@ -127,7 +127,7 @@
config DVB_BUDGET_PATCH
tristate AV7110 cards with Budget Patch
- depends on DVB_CORE DVB_BUDGET VIDEO_V4L1
+ depends on DVB_CORE DVB_BUDGET
select DVB_AV7110
select DVB_STV0299 if !DVB_FE_CUSTOMISE
select DVB_VES1X93 if !DVB_FE_CUSTOMISE
diff -bur v4l-dvb-7a6fab6d00a0_orig/linux/drivers/media/dvb/ttpci/av7110.c v4l-dvb-7a6fab6d00a0/linux/drivers/media/dvb/ttpci/av7110.c
--- v4l-dvb-7a6fab6d00a0_orig/linux/drivers/media/dvb/ttpci/av7110.c 2007-10-15 21:24:20.0 +0200
+++ v4l-dvb-7a6fab6d00a0/linux/drivers/media/dvb/ttpci/av7110.c 2007-10-15 21:32:02.0 +0200
@@ -2595,7 +2595,7 @@
mutex_init(av7110-osd_mutex);
/* TV standard */
- av7110-vidmode = tv_standard == 1 ? VIDEO_MODE_NTSC : VIDEO_MODE_PAL;
+ av7110-vidmode = tv_standard == 1 ? AV7110_VIDEO_MODE_NTSC : AV7110_VIDEO_MODE_PAL;
/* ARM watchdog */
init_waitqueue_head(av7110-arm_wait);
diff -bur v4l-dvb-7a6fab6d00a0_orig/linux/drivers/media/dvb/ttpci/av7110.h v4l-dvb-7a6fab6d00a0/linux/drivers/media/dvb/ttpci/av7110.h
--- v4l-dvb-7a6fab6d00a0_orig/linux/drivers/media/dvb/ttpci/av7110.h 2007-10-15 21:24:20.0 +0200
+++ v4l-dvb-7a6fab6d00a0/linux/drivers/media/dvb/ttpci/av7110.h 2007-10-15 21:32:30.0 +0200
@@ -50,6 +50,11 @@
enum {AV_PES_STREAM, PS_STREAM, TS_STREAM, PES_STREAM};
+enum av7110_video_mode {
+ AV7110_VIDEO_MODE_PAL = 0,
+ AV7110_VIDEO_MODE_NTSC = 1
+};
+
struct av7110_p2t {
u8 pes[TS_SIZE];
u8 counter;
@@ -182,7 +187,7 @@
ca_slot_info_t ci_slot[2];
- int vidmode;
+ enum av7110_video_mode vidmode;
struct dmxdev dmxdev;
struct dvb_demux demux;
diff -bur v4l-dvb-7a6fab6d00a0_orig/linux/drivers/media/dvb/ttpci/av7110_av.c v4l-dvb-7a6fab6d00a0/linux/drivers/media/dvb/ttpci/av7110_av.c
--- v4l-dvb-7a6fab6d00a0_orig/linux/drivers/media/dvb/ttpci/av7110_av.c 2007-10-15 21:24:20.0 +0200
+++ v4l-dvb-7a6fab6d00a0/linux/drivers/media/dvb/ttpci/av7110_av.c 2007-10-15 21:32:44.0 +0200
@@ -329,7 +329,7 @@
return 0;
}
-int av7110_set_vidmode(struct av7110 *av7110, int mode)
+int av7110_set_vidmode(struct av7110 *av7110, enum av7110_video_mode mode)
{
int ret;
dprintk(2, av7110:%p, \n, av7110);
@@ -348,11 +348,11 @@
}
-static int sw2mode[16] = {
- VIDEO_MODE_PAL, VIDEO_MODE_NTSC, VIDEO_MODE_NTSC, VIDEO_MODE_PAL,
- VIDEO_MODE_NTSC, VIDEO_MODE_NTSC, VIDEO_MODE_PAL, VIDEO_MODE_NTSC,
- VIDEO_MODE_PAL, VIDEO_MODE_PAL, VIDEO_MODE_PAL, VIDEO_MODE_PAL,
- VIDEO_MODE_PAL, VIDEO_MODE_PAL, VIDEO_MODE_PAL, VIDEO_MODE_PAL,
+static enum av7110_video_mode
Re: [linux-dvb] [Patch] stv0297: The value of the signal strength depends on the configuration of the agc polarity.
e9hack wrote: Hi, the attached patch fixes the increasing of the signal strength value (higher value = higher signal strength) and scales the value to the range of 0... The charcteristic itself is wrong. To get proper values on a TT-C2300 in the range of 40..60% real signal strength, the values from the patch should be divide by two. The attached patch doesn't fix the characteristic. Does this mean that you have a very high (80-100%) STR with this patch? Imho we may apply some heuristic to get sane values. We have 0 = tmp = 0x1ff. What about *strength = (tmp/2) * (tmp/2) ? CU Oliver -- VDR Remote Plugin 0.4.0: 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] [Patch] tda10021: The value of signal strength depends on the configuration of the agc polarity.
e9hack wrote: Hi, the attached patch fixes the increasing of the signal strength value (higher value = higher signal strength). If nobody objects I'll commit this patch. CU Oliver -- VDR Remote Plugin 0.4.0: 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] [Patch] tda10021: The ber counting must be reinitialized after reading of the values
e9hack wrote: Hi, the attached patch fixes the not working ber counting of the tda10021 frontend. If nobody objects I'll commit this patch. Thanks Oliver -- VDR Remote Plugin 0.4.0: 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] stv0297: improvement for qam256 modulated channels
e9hack wrote: Hi, I did eavesdrop the i2c-bus on the TT-C2300 on windows. The initialization of the stv0297 is a little bit different. If I change the value for the initial demodulation frequency, the ber value is reduced to a fourths. @all: please test with QAM256 channels and report any problems. If nobody objects I'll commit this patch. CU Oliver -- VDR Remote Plugin 0.4.0: 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] stv0297: improvement for qam256 modulated channels
Hi, Guy Martin wrote: On Sat, 27 Oct 2007 08:17:14 +0200 Oliver Endriss [EMAIL PROTECTED] wrote: e9hack wrote: I did eavesdrop the i2c-bus on the TT-C2300 on windows. The initialization of the stv0297 is a little bit different. If I change the value for the initial demodulation frequency, the ber value is reduced to a fourths. @all: please test with QAM256 channels and report any problems. If nobody objects I'll commit this patch. This breaks my cablestar. After applying the patch, I cannot lock any QAM256 channel. Thanks for reporting! Apparently we cannot use 6718 for all cards. So the patch must be modified... @TT/Hauppauge DVB-C 2300 users: Are there any problems with this patch? CU Oliver -- VDR Remote Plugin 0.4.0: 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] random memory corruptions with asus p7131 ( Re: asus p7131 vs ZDF?)
Soeren Sonnenburg wrote: On Wed, 2007-10-17 at 02:34 +0200, Oliver Endriss wrote: Soeren Sonnenburg wrote: On Sun, 2007-10-14 at 19:47 +0200, Oliver Endriss wrote: Soeren Sonnenburg wrote: On Fri, 2007-10-12 at 02:24 +0200, Oliver Endriss wrote: Soeren Sonnenburg wrote: [...] Well :-) If the tt-1500 turns out to work OK I can just once give the asus + your isolated patch a last chance before trashing it... Wait! Please clarify whether you think that your problem is caused by the _saa7134_ driver or the _saa7146_ driver. You wrote 'that memory corruption is caused by the saa7146 driver,' Is this a typo? Did you mean saa7134? You are right my statement is wrong. To get it right, my asus has the • tda10046a • saa7131e and not the saa7146 (which my brain generated using the numbers 7131 / 10046). Thanks for the clarification. (My patch is pointless if you do not run a saa7146-based card.) Well but I don't have problems with the saa7146 except for the random saa7146_i2c_writeout: timed out waiting for end of xfer which however do not seem to cause any harm... Hm - could you please test whether the patch decreases the number of saa7146_i2c_writeout messages? CU Oliver -- VDR Remote Plugin 0.4.0: 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] Common interface on Technotrend S-1500 broken in v4l-dvb?
P. van Gaans wrote:
On 10/14/2007 07:54 PM, Oliver Endriss wrote:
Oliver Endriss wrote:
P. van Gaans wrote:
On 10/14/2007 12:11 AM, Oliver Endriss wrote:
P. van Gaans wrote:
Today I was testing some stuff and downloaded and installed the newest
v4l-dvb from hg. After a while I figured out that FTA channels on my TT
S-1500 still worked, but the CAM would not respond. I checked all
connections, re-inserted the CAM, reboot the computer but nothing would
help. My CI daughterboard version is 1.1 and I bought this S-1500 end
of
august 2007. I use Ubuntu 7.04 with kernel 2.6.20-16-generic.
After installing a somewhat older version of v4l-dvb I luckily had left
on my harddisk, the common interface directly came back to life.
Could you please try to find out which changeset broke the code?
If you have a current HG checkout, you can update the driver to a given
version using 'hg update no of changeset'.
Maybe I just did something wrong somewhere, but would it be possible
some big change was made to the way the S-1500 handles the CI that
could
have broken it?
It's probably a change in budget-ci.c or dvb_ca_en50221.c
Just an educated guess:
Did http://linuxtv.org/hg/v4l-dvb/rev/b0a3a9b43d60
break the code? - 'hg update 6279'
CU
Oliver
6279 does not compile.
make -C /home/wn/v4l-dvb/v4l
make[1]: Entering directory `/home/wn/v4l-dvb/v4l'
perl scripts/make_config_compat.pl /lib/modules/2.6.20-16-generic/source
./.myconfig ./config-compat.h
File not found:
/lib/modules/2.6.20-16-generic/source/include/linux/netdevice.h at
scripts/make_config_compat.pl line 15.
make[1]: *** [config-compat.h] Error 2
make[1]: Leaving directory `/home/wn/v4l-dvb/v4l'
make: *** [all] Error 2
After trying a bit I figured out 6266 does compile. Everything between
6279 and 6266 does not. I can tell you that with 6266, the common
interface works, I hope that's enough info.
Now I have a confirmation from Marco Schluessler that changeset
http://linuxtv.org/hg/v4l-dvb/raw-rev/b0a3a9b43d60
broke CI support.
For now simply revert this changeset.
Save http://linuxtv.org/hg/v4l-dvb/raw-rev/b0a3a9b43d60 to a file.
Then use 'patch -p1 -R file' to revert the changeset.
Marco sent me the attached patch which should fix the problem.
Please test.
CU
Oliver
- while (!ca-wakeup) breaks the CAM initialisation
Signed-off-by: Marco Schluessler [EMAIL PROTECTED]
diff -bur
v4l-dvb-ea93c93f1547_orig/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
v4l-dvb-ea93c93f1547/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
---
v4l-dvb-ea93c93f1547_orig/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
2007-10-14 13:19:25.0 +0200
+++ v4l-dvb-ea93c93f1547/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
2007-10-14 18:37:15.0 +0200
@@ -973,7 +973,7 @@
/* main loop */
while (!kthread_should_stop()) {
/* sleep for a bit */
- while (!ca-wakeup) {
+ if (!ca-wakeup) {
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(ca-delay);
if (kthread_should_stop())
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
I wanted to test it but just downloaded the latest v4l-dvb and see the
patch is already applied. Common interface works with latest v4l-dvb
(oct 16 2007).
Correct, the patch has already been applied.
Thanks for testing!
CU
Oliver
--
VDR Remote Plugin 0.4.0: 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] random memory corruptions with asus p7131 (Re: asus p7131 vs ZDF?)
Soeren Sonnenburg wrote: On Sun, 2007-10-14 at 19:47 +0200, Oliver Endriss wrote: Soeren Sonnenburg wrote: On Fri, 2007-10-12 at 02:24 +0200, Oliver Endriss wrote: Soeren Sonnenburg wrote: I am unfortunately 100% sure that it is caused by the saa7146 driver, as I have an uptime of over a week now that it is not loaded (but the card is still in the slot, yeah and I did memory tests for 18 passes - nothing). Could you please try the patch posted in http://linuxtv.org/pipermail/linux-dvb/2007-October/021042.html and report whether it fixes your problem? Hmmhh, reading what it changes Two fixes for the 'saa7146_wait_for_debi_done' code: (a) Timeout did not work when the routine was called with interrupts disabled. (b) Reduce PCI I/O load caused by saa7146_wait_for_debi_done. Seems to be very important on fast machines! I am not sure why this could fix the problems I am seeing. I can give it a try if you are quite confident that it could help High load on the PCI bus might trigger a bug somewhere else. Btw, I'm not aware of any reports that the saa7146 driver caused memory corruption or something like that. Well it could be a bug in the asus p7131 firmware and the card just randomly doing weird things... and if this can be seen only after a few days of vdr/continuous use not many people may be affected and you may just not get reports. , but I get - gcc compile failures - filesystem corruptions - database corruptions Hm. Very often these symptoms are caused by broken hardware. I know. But as this machine has uptimes of months without this card (even with several pci slots in use and worked for long long times with very different cards in these slots) and it does not work when I just use the card instead of a win-tv or so I am sure that it is the the asus card which is not working correctly. Anyway I am now replacing that card with a tt-1500-t lets see whether strange things will happen or not. when the card's driver is loaded and is in use for a few days (and then finally a hang/crash+reboot). I have the *feeling* that the situation improved slightly by improving reception via F-connectors, so I thing there is some kind of buffer overflow or so occurring... Anyway thanks for your work, I will happily try it if you think it may fix this problem. I would try. ;-) Well :-) If the tt-1500 turns out to work OK I can just once give the asus + your isolated patch a last chance before trashing it... Wait! Please clarify whether you think that your problem is caused by the _saa7134_ driver or the _saa7146_ driver. You wrote 'that memory corruption is caused by the saa7146 driver,' Is this a typo? Did you mean saa7134? (My patch is pointless if you do not run a saa7146-based card.) CU Oliver -- VDR Remote Plugin 0.4.0: 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] [saa7134] Fwd: [PATCH] Spezial Lifeview DVB-S Card without eeprom
Hi,
since there was no reply on the DVB ML:
Is anyone maintaining the DVB part of the saa7134 driver?
Can this patch be accepted?
CU
Oliver
-- Forwarded Message --
Subject: [linux-dvb] [PATCH] Spezial Lifeview DVB-S Card without eeprom
Date: Sunday 14 October 2007 22:12
From: Martin Dauskardt [EMAIL PROTECTED]
To: linux-dvb@linuxtv.org
The patch has already been posted in May by Michael Möhle without getting
attention: http://linuxtv.org/pipermail/linux-dvb/2007-May/018007.html
Several users in the german vdrportal forum use this card, therefore the patch
is included in my LinVDR kernel package since months.
To patch should really be included into the hg.
I attach a diff against hg from today. It is still the same patch originally
written by Ralph Metzler.
Greets,
Martin Dauskardt
---
--
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
diff -ur v4l-dvb-ea93c93f1547-orig/linux/drivers/media/video/saa7134/saa7134-cards.c v4l-dvb-ea93c93f1547/linux/drivers/media/video/saa7134/saa7134-cards.c
--- v4l-dvb-ea93c93f1547-orig/linux/drivers/media/video/saa7134/saa7134-cards.c 2007-10-11 14:09:06.0 +0200
+++ v4l-dvb-ea93c93f1547/linux/drivers/media/video/saa7134/saa7134-cards.c 2007-10-14 17:48:49.0 +0200
@@ -3591,6 +3591,26 @@
.tv = 1,
}},
},
+ [SAA7134_BOARD_LIFEVIEW_DVBS] = {
+ /* LifeView FlyDVB-s */
+ /* Ralph Metzler [EMAIL PROTECTED] */
+ .name = LifeView FlyDVB-S,
+ .audio_clock= 0x0020,
+ .tuner_type = TUNER_ABSENT,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .mpeg = SAA7134_MPEG_DVB,
+ .inputs = {{
+ .name = name_comp1, /* Composite input */
+ .vmux = 3,
+ .amux = LINE1,
+ },{
+ .name = name_svideo, /* S-Video signal on S-Video input */
+ .vmux = 8,
+ .amux = LINE1,
+ }},
+ },
};
const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
Nur in v4l-dvb-ea93c93f1547/linux/drivers/media/video/saa7134: saa7134-cards.c.orig.
diff -ur v4l-dvb-ea93c93f1547-orig/linux/drivers/media/video/saa7134/saa7134-dvb.c v4l-dvb-ea93c93f1547/linux/drivers/media/video/saa7134/saa7134-dvb.c
--- v4l-dvb-ea93c93f1547-orig/linux/drivers/media/video/saa7134/saa7134-dvb.c 2007-10-11 14:09:06.0 +0200
+++ v4l-dvb-ea93c93f1547/linux/drivers/media/video/saa7134/saa7134-dvb.c 2007-10-14 17:48:49.0 +0200
@@ -43,6 +43,8 @@
#include tda826x.h
#include tda827x.h
#include isl6421.h
+#include tua6100.h
+#include stv0299.h
MODULE_AUTHOR(Gerd Knorr [EMAIL PROTECTED] [SuSE Labs]);
MODULE_LICENSE(GPL);
@@ -839,6 +841,130 @@
.demod_address= 0x0a,
};
+/* -- */
+
+static int philips_su1278_ty_ci_tuner_set_params(struct dvb_frontend *fe,
+ struct dvb_frontend_parameters *params)
+{
+ u32 div;
+ u8 buf[4];
+ struct saa7134_dev *dev = fe-dvb-priv;
+ struct i2c_msg msg = {.addr = 0x61,.flags = 0,.buf = buf,.len = sizeof(buf) };
+
+ if ((params-frequency 95) || (params-frequency 215))
+ return -EINVAL;
+
+ div = (params-frequency + (125 - 1)) / 125; // round correctly
+ buf[0] = (div 8) 0x7f;
+ buf[1] = div 0xff;
+ buf[2] = 0x80 | ((div 0x18000) 10) | 4;
+ buf[3] = 0x20;
+
+ if (params-u.qpsk.symbol_rate 400)
+ buf[3] |= 1;
+
+ if (params-frequency 125)
+ buf[3] |= 0;
+ else if (params-frequency 155)
+ buf[3] |= 0x40;
+ else if (params-frequency 205)
+ buf[3] |= 0x80;
+ else if (params-frequency 215)
+ buf[3] |= 0xC0;
+
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 1);
+ if (i2c_transfer(dev-i2c_adap, msg, 1) != 1)
+ return -EIO;
+ return 0;
+}
+
+static int lifeview_set_symbol_rate(struct dvb_frontend *fe, u32 srate, u32 ratio)
+{
+ u8 aclk = 0;
+ u8 bclk = 0;
+ u8 m1;
+
+ aclk = 0xb5;
+ if (srate 200)
+ bclk = 0x86;
+ else if (srate 500)
+ bclk = 0x89;
+ else if (srate 1500)
+ bclk = 0x8f;
+ else if (srate 4500)
+ bclk = 0x95;
+
+ m1 = 0x14;
+ if (srate 400)
+ m1 = 0x10;
+
+ stv0299_writereg(fe, 0x13, aclk);
+ stv0299_writereg(fe, 0x14, bclk);
+ stv0299_writereg(fe, 0x1f, (ratio 16) 0xff);
+ stv0299_writereg(fe, 0x20, (ratio 8) 0xff);
+ stv0299_writereg(fe, 0x21, (ratio) 0xf0);
+ stv0299_writereg(fe, 0x0f, 0x80 | m1);
+
+ return 0;
+}
+
+static u8 lifeview_inittab[] = {
+ 0x01, 0x15,
+ 0x02, 0x30,
+ 0x03, 0x00,
+ 0x04, 0x7d, /* F22FR = 0x7d, F22 = f_VCO / 128 / 0x7d = 22 kHz */
+ 0x05, 0x35, /* I2CT = 0, SCLT = 1, SDAT = 1 */
+ 0x06, 0x40, /* DAC not used, set to high impendance mode */
+ 0x07, 0x00, /* DAC LSB */
+ 0x08, 0x40, /* DiSEqC off */
+ 0x09, 0x00, /* FIFO */
+ 0x0c, 0x51, /* OP1 ctl = Normal, OP1 val = 1 (LNB Power ON) */
+ 0x0d, 0x82, /* DC offset compensation = ON,
Re: [linux-dvb] [Patch] saa7146: 'wait_for_debi_done' fixes
Tomi Orava wrote: Tomi Orava schrieb: I tried your patch and for me it resulted the following constant complaints: saa7146 (0): saa7146_wait_for_debi_done_sleep timed out while waiting for transfer completion saa7146 (0): saa7146_wait_for_debi_done_sleep timed out while waiting for transfer completion saa7146 (0): saa7146_wait_for_debi_done_sleep timed out while waiting for transfer completion The above complaint started as soon MythBackend started hopping from channel to channel and gathering EIT-information. These messages came every once couple of minutes until I stopped the test run. Oliver did changed two DEB_S() to printk. If you replace the DEB_S() with printk (or enable debug output) in saa7146_wait_for_debi_done() within a clean tree, probably you will get the same messages. You are correct. I do get the same message if I change the DEB_S to printk for a test run. Any ideas how to modify the system/settings not to error all the time (and I don't mean the actual error message) ? Somehow I think that this machine should finally be capable of handling all three DVB-C cards without hicups (AMD X2 5600, asus crosshair etc etc). AFAICS the budget-av driver is triggering the log messages. Is a CI connected to the Satelco EasyWatch DVB-C MK3? If not I guess that the DEBI timeouts are normal because there is no hardware connected to the debi bus. In this case I'd have to revert the code to 'DEBI_S' because those timeouts are normal. ;-( CU Oliver -- VDR Remote Plugin 0.4.0: 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] Technotrend DVB-T 1200 rev 1.2 does not tune/work
Soeren Sonnenburg wrote: On Sun, 2007-10-14 at 18:53 +0200, Oliver Endriss wrote: Soeren Sonnenburg wrote: On Sun, 2007-10-14 at 16:03 +0200, Oliver Endriss wrote: Soeren Sonnenburg wrote: On Sat, 2007-10-13 at 23:52 +0200, Oliver Endriss wrote: Soeren Sonnenburg wrote: Dear all, [...] Did this card ever work before? I just purchased it, so I cannot tell whether it ever worked with linux. However the guy from whom I got the card claimed that it works w/ windows. Please try it with windows. Then we will know whether it is ok or not. The problem is that I do not easily have access to a windows machine. Is there anything I can do to test whether it is OK without windows? ... I mean the problem is, that the frontend registers and loads the sp8870 firmware, but I have no idea whether that is the right one or not (it does not want the grundig frontend however)... Afaik there are only those two frontends for DVB-T FF cards. OK. When I scan it does not find any channel and using a channel list obtained via a budget tt card, it still does not want to tune to any channel there... Any ideas? I mean not that because the card is considered dvb-s some potentially wrong dvb-s settings are set somewhere?! Afaics you did everything which could be done. The frontend was detected. Basically the card should work. (I assume that there are no tuning-related error messages in the log.) no, nothing. Next you have to find out whether the card is broken or not. From your results I guess something is broken, but you can only be sure if you test it with the windows driver. (There is a small chance that it is a card variant which is not supported yet.) OK, I convinced someone to try the card under windows and well scanning worked, for all the expected channels and we could tune... So the card works. And we used that old tt_Premium_217g.zip driver... so I guess it should work with linux too... However also under windows it said dvb-s although we could load the driver. Ok, the card works. There are two possibilities: - The frontend driver is broken. - The card is somehow different from those supported by the driver, and a special handling is required. @all: Can someone confirm that the current dvb-ttpci driver works for DVB-T FF cards (ALPS TDLB7 tuner, sp8870-based)? CU Oliver -- VDR Remote Plugin 0.4.0: 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] Technotrend DVB-T 1200 rev 1.2 does not tune/work
Soeren Sonnenburg wrote: On Sun, 2007-10-14 at 16:03 +0200, Oliver Endriss wrote: Soeren Sonnenburg wrote: On Sat, 2007-10-13 at 23:52 +0200, Oliver Endriss wrote: Soeren Sonnenburg wrote: Dear all, [...] Did this card ever work before? I just purchased it, so I cannot tell whether it ever worked with linux. However the guy from whom I got the card claimed that it works w/ windows. Please try it with windows. Then we will know whether it is ok or not. The problem is that I do not easily have access to a windows machine. Is there anything I can do to test whether it is OK without windows? ... I mean the problem is, that the frontend registers and loads the sp8870 firmware, but I have no idea whether that is the right one or not (it does not want the grundig frontend however)... Afaik there are only those two frontends for DVB-T FF cards. When I scan it does not find any channel and using a channel list obtained via a budget tt card, it still does not want to tune to any channel there... Any ideas? I mean not that because the card is considered dvb-s some potentially wrong dvb-s settings are set somewhere?! Afaics you did everything which could be done. The frontend was detected. Basically the card should work. (I assume that there are no tuning-related error messages in the log.) Next you have to find out whether the card is broken or not. From your results I guess something is broken, but you can only be sure if you test it with the windows driver. (There is a small chance that it is a card variant which is not supported yet.) CU Oliver -- VDR Remote Plugin 0.4.0: 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] random memory corruptions with asus p7131 (Re: asus p7131 vs ZDF?)
Soeren Sonnenburg wrote: On Fri, 2007-10-12 at 02:24 +0200, Oliver Endriss wrote: Soeren Sonnenburg wrote: I am unfortunately 100% sure that it is caused by the saa7146 driver, as I have an uptime of over a week now that it is not loaded (but the card is still in the slot, yeah and I did memory tests for 18 passes - nothing). Could you please try the patch posted in http://linuxtv.org/pipermail/linux-dvb/2007-October/021042.html and report whether it fixes your problem? Hmmhh, reading what it changes Two fixes for the 'saa7146_wait_for_debi_done' code: (a) Timeout did not work when the routine was called with interrupts disabled. (b) Reduce PCI I/O load caused by saa7146_wait_for_debi_done. Seems to be very important on fast machines! I am not sure why this could fix the problems I am seeing. I can give it a try if you are quite confident that it could help High load on the PCI bus might trigger a bug somewhere else. Btw, I'm not aware of any reports that the saa7146 driver caused memory corruption or something like that. , but I get - gcc compile failures - filesystem corruptions - database corruptions Hm. Very often these symptoms are caused by broken hardware. when the card's driver is loaded and is in use for a few days (and then finally a hang/crash+reboot). I have the *feeling* that the situation improved slightly by improving reception via F-connectors, so I thing there is some kind of buffer overflow or so occurring... Anyway thanks for your work, I will happily try it if you think it may fix this problem. I would try. ;-) CU Oliver -- VDR Remote Plugin 0.4.0: 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] Technotrend DVB-T 1200 rev 1.2 does not tune/work
Soeren Sonnenburg wrote: Dear all, I am having problems with a full featured TT-1200 dvb-t (sometimes also called technotrend dvb-t premium) card. It does not find the frontend and if I manually fiddle with the code (I simply had to remove the break in line 2176 of av7110.c in hg to allow There is no 'break' on line 2176, should be 2167. (?) fallthrough) to make it load the Spase SP8870 DVB-T it successfully registers this frontend and loads the sp8870 firmware but then it still refuses to tune to any channel... Did this card ever work before? As the card is listed as supported I am a bit confused what is going on - any ideas? Soeren Details follow: kernel is 2.6.23.1 #lspci 00:0b.0 0480: 1131:7146 (rev 01) Subsystem: 13c2: This sub-system id is normally used by DVB-S cards. Apparently there is one more exception. :-( # dmesg dvb-ttpci: info @ card 2: firm f0240009, rtsl b0250018, vid 71010068, app 80f12623 dvb-ttpci: firmware @ card 2 supports CI link layer interface dvb-ttpci: Crystal audio DAC @ card 2 detected saa7146_vv: saa7146 (2): registered device video1 [v4l2] saa7146_vv: saa7146 (2): registered device vbi1 [v4l2] ves1820: ves1820_readreg(): readreg error (reg == 0x1a,ret == -121) DVB: registering frontend 2 (Spase SP8870 DVB-T)... input: DVB on-card IR receiver as /devices/pci:00/:00:0b.0/input/input9 dvb-ttpci: found av7110-1. hires photo taken of the card or further info on request... Is this your card? http://vdr-wiki.de/wiki/index.php/DVB-T_full-featured-Karten Please note that this card is not able to tune to VHF channels! CU Oliver -- VDR Remote Plugin 0.4.0: 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] TT-2300 with IR on CI - not work??
Simon Baxter wrote: Hi I have a new TT-2300 DVB-C FF card with the associated CI module with in-built IR receiver. The IR seems to register fine: dmesg: input: DVB on-card IR receiver as /class/input/input3 It always registers, no matter whether there is an ir receiver or not. ...and I've added the little jumper on the CI - but it won't work. I do a 'tail -f /dev/input/event3' and get nothing when pointing the remote at it. This will only work if you have loaded a keymap. Similarly get nothing with VDR and the vdr-remote plugin. Any ideas??? Is the IR receiver connected to the card or to the CI? From remote plugin FAQ: | 2.2.1 The remote control does not work, if a CI is connected | -- | Whenever a CI is connected, the on-board connector will be disabled! | | On some CIs there is a jumper to select whether the receiver of the CI | or the receiver of the FF-card should be used. RTFM. | | If not, use the integrated receiver of the CI, | or connect the receiver to the ir connector of the CI. Another solution posted by [EMAIL PROTECTED]: http://www.vdr-portal.de/board/thread.php?postid=652902#post652902 (Remove the 0 Ohm resistor.) CU Oliver -- VDR Remote Plugin 0.4.0: 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] Common interface on Technotrend S-1500 broken in v4l-dvb?
P. van Gaans wrote: Today I was testing some stuff and downloaded and installed the newest v4l-dvb from hg. After a while I figured out that FTA channels on my TT S-1500 still worked, but the CAM would not respond. I checked all connections, re-inserted the CAM, reboot the computer but nothing would help. My CI daughterboard version is 1.1 and I bought this S-1500 end of august 2007. I use Ubuntu 7.04 with kernel 2.6.20-16-generic. After installing a somewhat older version of v4l-dvb I luckily had left on my harddisk, the common interface directly came back to life. Could you please try to find out which changeset broke the code? If you have a current HG checkout, you can update the driver to a given version using 'hg update no of changeset'. Maybe I just did something wrong somewhere, but would it be possible some big change was made to the way the S-1500 handles the CI that could have broken it? It's probably a change in budget-ci.c or dvb_ca_en50221.c Just an educated guess: Did http://linuxtv.org/hg/v4l-dvb/rev/b0a3a9b43d60 break the code? - 'hg update 6279' CU Oliver -- VDR Remote Plugin 0.4.0: 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] Future of Multiproto
Marcel Siegert wrote: can everybody _please_ stop this unnessessary discussion? Full ack! I'm really tired reading these garbage threads. @all, I suggest the following: 1a Review the API extensions (dvb_frontend.h). 1b Commit them. 2a Review dvb_core modifications. 2b Commit them. 3 Commit drivers when they are ready for inclusion. CU Oliver -- VDR Remote Plugin 0.4.0: 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] random memory corruptions with asus p7131 (Re: asus p7131 vs ZDF?)
Soeren Sonnenburg wrote: I am unfortunately 100% sure that it is caused by the saa7146 driver, as I have an uptime of over a week now that it is not loaded (but the card is still in the slot, yeah and I did memory tests for 18 passes - nothing). Could you please try the patch posted in http://linuxtv.org/pipermail/linux-dvb/2007-October/021042.html and report whether it fixes your problem? CU Oliver -- VDR Remote Plugin 0.4.0: 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] Re : [Patch] saa7146: 'wa it_for_debi_done' fixes
manu wrote: On 10/09/2007 06:15:14 PM, Oliver Endriss wrote: @all users of saa7146-based cards (drivers: dvb-ttpci, budget, budget-ci, budget-av) Please test whether the attached patch has any negative effects. Two fixes for the 'saa7146_wait_for_debi_done' code: (a) Timeout did not work when the routine was called with interrupts disabled. (b) Reduce PCI I/O load caused by saa7146_wait_for_debi_done. Seems to be very important on fast machines! Based on a patch posted by [EMAIL PROTECTED] If nobody complains I will commit this patch next week. Well sorry it seems to create an oops on my box. Just to make sure though: it is the first time I compile and load modules from mercurial and so could it just be a compatibility problem with my 2.6.20-16 Ubuntu Feisty kernel? Please make sure that you do not mix v4l/dvb modules from the original kernel and the HG driver, or you will see all kinds of crashes. First try the HG driver without my patch. If it works, apply the patch and try again. CU Oliver -- VDR Remote Plugin 0.4.0: 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] [Patch] saa7146: 'wait_for_debi_done' fixes
@all users of saa7146-based cards
(drivers: dvb-ttpci, budget, budget-ci, budget-av)
Please test whether the attached patch has any negative effects.
Two fixes for the 'saa7146_wait_for_debi_done' code:
(a) Timeout did not work when the routine was called with interrupts
disabled.
(b) Reduce PCI I/O load caused by saa7146_wait_for_debi_done.
Seems to be very important on fast machines!
Based on a patch posted by [EMAIL PROTECTED]
If nobody complains I will commit this patch next week.
CU
Oliver
--
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
diff -r 54b01562b12d linux/drivers/media/common/saa7146_core.c
--- a/linux/drivers/media/common/saa7146_core.c Tue Oct 09 22:58:39 2007 +0200
+++ b/linux/drivers/media/common/saa7146_core.c Tue Oct 09 23:54:20 2007 +0200
@@ -59,41 +59,85 @@ void saa7146_setgpio(struct saa7146_dev
}
/* This DEBI code is based on the saa7146 Stradis driver by Nathan Laredo */
-int saa7146_wait_for_debi_done(struct saa7146_dev *dev, int nobusyloop)
-{
- unsigned long start;
+static inline int saa7146_wait_for_debi_done_sleep(struct saa7146_dev *dev,
+unsigned long us1, unsigned long us2)
+{
+ unsigned long timeout;
int err;
/* wait for registers to be programmed */
- start = jiffies;
+ timeout = jiffies + usecs_to_jiffies(us1);
while (1) {
- err = time_after(jiffies, start + HZ/20);
+ err = time_after(jiffies, timeout);
if (saa7146_read(dev, MC2) 2)
break;
if (err) {
- DEB_S((timed out while waiting for registers getting programmed\n));
+ printk(KERN_ERR %s: %s timed out while waiting for registers getting programmed\n,
+ dev-name, __FUNCTION__);
return -ETIMEDOUT;
}
- if (nobusyloop)
- msleep(1);
+ msleep(1);
}
/* wait for transfer to complete */
- start = jiffies;
+ timeout = jiffies + usecs_to_jiffies(us2);
while (1) {
- err = time_after(jiffies, start + HZ/4);
+ err = time_after(jiffies, timeout);
if (!(saa7146_read(dev, PSR) SPCI_DEBI_S))
break;
saa7146_read(dev, MC2);
if (err) {
- DEB_S((timed out while waiting for transfer completion\n));
+ printk(KERN_ERR %s: %s timed out while waiting for transfer completion\n,
+ dev-name, __FUNCTION__);
return -ETIMEDOUT;
}
- if (nobusyloop)
- msleep(1);
+ msleep(1);
}
return 0;
+}
+
+static inline int saa7146_wait_for_debi_done_busyloop(struct saa7146_dev *dev,
+unsigned long us1, unsigned long us2)
+{
+ unsigned long loops;
+
+ /* wait for registers to be programmed */
+ loops = us1;
+ while (1) {
+ if (saa7146_read(dev, MC2) 2)
+ break;
+ if (!loops--) {
+ printk(KERN_ERR %s: %s timed out while waiting for registers getting programmed\n,
+ dev-name, __FUNCTION__);
+ return -ETIMEDOUT;
+ }
+ udelay(1);
+ }
+
+ /* wait for transfer to complete */
+ loops = us2 / 5;
+ while (1) {
+ if (!(saa7146_read(dev, PSR) SPCI_DEBI_S))
+ break;
+ saa7146_read(dev, MC2);
+ if (!loops--) {
+ printk(KERN_ERR %s: %s timed out while waiting for transfer completion\n,
+ dev-name, __FUNCTION__);
+ return -ETIMEDOUT;
+ }
+ udelay(5);
+ }
+
+ return 0;
+}
+
+int saa7146_wait_for_debi_done(struct saa7146_dev *dev, int nobusyloop)
+{
+ if (nobusyloop)
+ return saa7146_wait_for_debi_done_sleep(dev, 5, 25);
+ else
+ return saa7146_wait_for_debi_done_busyloop(dev, 5, 25);
}
/
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] budget-av/CI-interface with SMP
Julian Scheel wrote: Am Freitag 17 August 2007 04:04 schrieb Oliver Endriss: Same problem as before: Must not sleep within spinlock-ed code. If I disable nobusyloop the errors are gone. I will check if the CI-module keeps working properly. If I disable nobusyloop the system becomes unresponsive after a while without CAM plugged. Does the machine freeze completely? No error messages on the console? It only gets very slow then. Does it work with CAM plugged, or does it freeze, too? With CAM plugged it was fine, I think. Please post the patch you are currently using. Attached is the patch I use, against Manus latest multiproto tree. Should apply with some offset to the official tree, too. Could you please try the patch posted in http://linuxtv.org/pipermail/linux-dvb/2007-October/021042.html Afaics it might fix the underlying problem. Sorry for the delay, hadn't had much time last weeks. Same problem here. ;-( CU Oliver -- VDR Remote Plugin 0.4.0: 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] [Patch] ves1820: increase acquisition range for clock recovery
@all users of ves1820-based DVB-C cards (FF ttpci, budget),
please test whether the attached patch has any adverse effects.
(Tests @vdr-portal did not show any problems yet.)
It changes the acquisition range for clock recovery from 120 ppm to
240ppm. Apparently, some cable providers in Germany are playing with
their parameters, and the capture range of the ves1820 is too small
to acquire a lock with the current setting... ;-(
If nobody complains I will commit this patch next weekend.
CU
Oliver
--
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
diff -r 21dd007fdc59 linux/drivers/media/dvb/frontends/ves1820.c
--- a/linux/drivers/media/dvb/frontends/ves1820.c Thu Oct 04 22:36:22 2007 +0200
+++ b/linux/drivers/media/dvb/frontends/ves1820.c Sat Oct 06 16:55:35 2007 +0200
@@ -47,7 +47,7 @@ static int verbose;
static int verbose;
static u8 ves1820_inittab[] = {
- 0x69, 0x6A, 0x93, 0x12, 0x12, 0x46, 0x26, 0x1A,
+ 0x69, 0x6A, 0x93, 0x1A, 0x12, 0x46, 0x26, 0x1A,
0x43, 0x6A, 0xAA, 0xAA, 0x1E, 0x85, 0x43, 0x20,
0xE0, 0x00, 0xA1, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00,
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Asys P7131 Hybrid: DVB out of range
Trent Piepho wrote: On Thu, 6 Sep 2007, hermann pitton wrote: Am Mittwoch, den 05.09.2007, 13:29 +0200 schrieb Paolo Dell'Aquila: Than I've done some test with Mythtv and auto-scanning for channels... and now... ...now I'm having the following (BIG) problem: dvb-t doesn't work anymore (also in kaffeiene or tzap). dmesg has the following error: DVB: frontend 0 frequency 2147483647 out of range (5100..85800) That sounds really mad, especially as you are in freq. limits of the tda8275 and not of the tda8275a, which for sure you have. The limits are comming from the tda10046 info. I think the correct thing to do here is to not have the tda1004x driver define frequency limits, as it's the tuner that has the limits. Nak. You must not remove these limits unless you make sure that all tuner drivers which might be attached to this demod have non-zero frequency limits. But, 2147483647 is not a valid DVB-T frequency. It looks like some random number. Ack, this frequency is bogus. The application must be fixed. 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] [RFC] Hybrid tuner refactoring, phase 1
Michael Krufky wrote: 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. While I currently don't have the time to completely review all changesets, the proposal looks fine to me. The dvb_frontend extensions are ok. Acked-by: Oliver Endriss [EMAIL PROTECTED] CU Oliver -- VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr
Re: [linux-dvb] [PATCH] add device node locking possibility to dvbcore
Johannes Stezenbach wrote: On Sun, Aug 19, 2007, Oliver Endriss wrote: Questions: - Why should dvb_shutdown_timeout==0 disable sleep mode? The use case was to watch video without any software running. Just program the hardware once and let it do it's job. Some people want that although I don't think it's really useful. (Works for FF cards only, of course.) - Does it make any sense to have LNB power 'on' and the frontend in sleep mode? No. Imho these should be controlled by dvb_powerdown_on_sleep alone, for example: Sounds good to me. Ok. Default value for dvb_shutdown_timeout set to 0: http://linuxtv.org/hg/v4l-dvb/rev/56556c094e04 dvb_powerdown_on_sleep controls fe sleep _and_ LNB power: http://linuxtv.org/hg/v4l-dvb/rev/9b00ad43d7f3 ts_bus_ctrl fixed: http://linuxtv.org/hg/v4l-dvb/rev/e09c063c28dd Afaics fe locking can be done using ts_bus_ctrl now (iff dvb_shutdown_timeout == 0). 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] only one read access to cx88-devices possible
Fabian Förg wrote:
Hello,
I realized that only one read access is possible to devices that use the
cx88 driver.
In my case it is a Hauppauge WinTV Nova-S-Plus DVB-S card.
You can reproduce it with the following test:
Launch femon concurrently two or more times. Only one femon is able to
read from the card.
Oliver Endriss confirmed that bug after looking in cx88-dvb.c.
Usually, only one write access but an arbitrary amount of read accesses
should be allowed.
Basically it's a bug in dvb_frontend.
ts_bus_ctrl() should only be called by
- the first open
- the last release
call.
Please try the attached patch.
@all:
Ok?
CU
Oliver
--
VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/
diff -r abb4c177bf6c linux/drivers/media/dvb/dvb-core/dvb_frontend.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Wed Aug 22 00:46:48 2007 +0200
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Thu Aug 23 01:13:49 2007 +0200
@@ -1061,18 +1061,15 @@ static int dvb_frontend_open(struct inod
dprintk (%s\n, __FUNCTION__);
+ if (dvbdev-users == -1 fe-ops.ts_bus_ctrl) {
+ if ((ret = fe-ops.ts_bus_ctrl(fe, 1)) 0)
+ return ret;
+ }
+
if ((ret = dvb_generic_open (inode, file)) 0)
- return ret;
-
- if (fe-ops.ts_bus_ctrl) {
- if ((ret = fe-ops.ts_bus_ctrl (fe, 1)) 0) {
- dvb_generic_release (inode, file);
- return ret;
- }
- }
+ goto err1;
if ((file-f_flags O_ACCMODE) != O_RDONLY) {
-
/* normal tune mode when opened R/W */
fepriv-tune_mode_flags = ~FE_TUNE_MODE_ONESHOT;
fepriv-tone = -1;
@@ -1080,13 +1077,20 @@ static int dvb_frontend_open(struct inod
ret = dvb_frontend_start (fe);
if (ret)
- dvb_generic_release (inode, file);
+ goto err2;
/* empty event queue */
fepriv-events.eventr = fepriv-events.eventw = 0;
}
return ret;
+
+err2:
+ dvb_generic_release(inode, file);
+err1:
+ if (dvbdev-users == -1 fe-ops.ts_bus_ctrl)
+ fe-ops.ts_bus_ctrl(fe, 0);
+ return ret;
}
static int dvb_frontend_release(struct inode *inode, struct file *file)
@@ -1101,16 +1105,18 @@ static int dvb_frontend_release(struct i
if ((file-f_flags O_ACCMODE) != O_RDONLY)
fepriv-release_jiffies = jiffies;
- if (fe-ops.ts_bus_ctrl)
- fe-ops.ts_bus_ctrl (fe, 0);
-
ret = dvb_generic_release (inode, file);
- if (dvbdev-users==-1 fepriv-exit==1) {
- fops_put(file-f_op);
- file-f_op = NULL;
- wake_up(dvbdev-wait_queue);
- }
+ if (dvbdev-users == -1) {
+ if (fepriv-exit == 1) {
+ fops_put(file-f_op);
+ file-f_op = NULL;
+ wake_up(dvbdev-wait_queue);
+ }
+ if (fe-ops.ts_bus_ctrl)
+ fe-ops.ts_bus_ctrl(fe, 0);
+ }
+
return ret;
}
___
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
e9hack wrote: Oliver Endriss schrieb: 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 I saw the same messages, if I used a too short delay (100usec). For testing, I printed out the time, while the DEBI_E was active. Startup of the TT-C2300: Aug 19 08:53:38 darkstar kernel: Linux video capture interface: v2.00 Aug 19 08:53:38 darkstar kernel: saa7146: register extension 'dvb'. Aug 19 08:53:38 darkstar kernel: ACPI: PCI Interrupt :04:06.0[A] - Link [LNKA] - GSI 17 (level, low) - IRQ 22 Aug 19 08:53:38 darkstar kernel: saa7146: found saa7146 @ mem fab6ec00 (revision 1, irq 22) (0x13c2,0x000a). Aug 19 08:53:38 darkstar kernel: DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-CA rev1.X) Aug 19 08:53:38 darkstar kernel: adapter has MAC addr = ??:??:??:??:??:?? Aug 19 08:53:38 darkstar kernel: (saa7146_core.c:136) saa7146 (0): SEBI_E was active for 30usec Aug 19 08:53:38 darkstar kernel: (saa7146_core.c:136) saa7146 (0): SEBI_E was active for 360usec Aug 19 08:53:38 darkstar kernel: (saa7146_core.c:136) saa7146 (0): SEBI_E was active for 360usec Aug 19 08:53:38 darkstar kernel: (saa7146_core.c:136) saa7146 (0): SEBI_E was active for 360usec Aug 19 08:53:38 darkstar kernel: (saa7146_core.c:136) saa7146 (0): SEBI_E was active for 360usec Aug 19 08:53:38 darkstar kernel: (saa7146_core.c:136) saa7146 (0): SEBI_E was active for 360usec Aug 19 08:53:38 very-new-darkstar kernel: vdr is running: Aug 19 08:59:33 darkstar kernel: (saa7146_core.c:132) saa7146 (1): SEBI_E was active for 38(253)msec Aug 19 08:59:33 darkstar kernel: (saa7146_core.c:132) saa7146 (1): SEBI_E was active for 38(253)msec Aug 19 08:59:33 darkstar kernel: (saa7146_core.c:136) saa7146 (0): SEBI_E was active for 20usec Aug 19 08:59:33 darkstar kernel: (saa7146_core.c:132) saa7146 (1): SEBI_E was active for 38(253)msec Aug 19 08:59:34 darkstar kernel: (saa7146_core.c:132) saa7146 (1): SEBI_E was active for 38(253)msec Aug 19 08:59:34 darkstar kernel: (tda10021.c:305) ckoff=26, sroffset=672, sr=690 Aug 19 08:59:34 darkstar kernel: (saa7146_core.c:136) saa7146 (0): SEBI_E was active for 30usec Aug 19 08:59:34 darkstar kernel: (tda10021.c:305) ckoff=0, sroffset=0, sr=6900672 Aug 19 08:59:34 darkstar kernel: (saa7146_core.c:132) saa7146 (1): SEBI_E was active for 38(253)msec Aug 19 08:59:34 darkstar kernel: (saa7146_core.c:132) saa7146 (1): SEBI_E was active for 38(253)msec Aug 19 08:59:35 darkstar kernel: (saa7146_core.c:132) saa7146 (1): SEBI_E was active for 38(253)msec Aug 19 08:59:35 darkstar kernel: (saa7146_core.c:136) saa7146 (0): SEBI_E was active for 110usec The longest time from the TT-C2300 was 370us. The Cinergy does always timeout with a debi error. I've used the attached patch. For full-featured cards it may take some time until the debi transfer has completed, because those cards use debi dma. I wonder - why the error bit gets set at all, and. - whether the debi status bits are updated before the transfer has been completed/stopped. I'll try to look into this next week. 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] [PATCH] add device node locking possibility to dvbcore
Manu Abraham wrote:
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.
Hm, for FF cards there is another voodoo parameter in dvb-ttpci:
'pids_off:clear video/audio/PCR PID filters when demux is closed'
Default is 0 which means don't close. ;-(
For FF cards there is one useful(?) application:
If someone does not want to keep szap running after tuning,
he might want to set dvb_shutdown_timeout=0.
This will both
- terminate the fe thread, and
- disable frontend powerdown.
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.
Afaics there are several features mixed-up with this parameter:
if (dvb_shutdown_timeout) {
if (dvb_powerdown_on_sleep)
if (fe-ops.set_voltage)
fe-ops.set_voltage(fe, SEC_VOLTAGE_OFF);
if (fe-ops.tuner_ops.sleep) {
fe-ops.tuner_ops.sleep(fe);
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0);
}
if (fe-ops.sleep)
fe-ops.sleep(fe);
}
Questions:
- Why should dvb_shutdown_timeout==0 disable sleep mode?
- Does it make any sense to have LNB power 'on' and the frontend in
sleep mode?
Imho these should be controlled by dvb_powerdown_on_sleep alone,
for example:
if (dvb_powerdown_on_sleep) {
if (fe-ops.set_voltage)
fe-ops.set_voltage(fe, SEC_VOLTAGE_OFF);
if (fe-ops.tuner_ops.sleep) {
fe-ops.tuner_ops.sleep(fe);
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0);
}
if (fe-ops.sleep)
fe-ops.sleep(fe);
}
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
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] [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] [PATCH] add device node locking possibility to dvbcore
Markus Rechberger wrote:
On 8/17/07, Oliver Endriss [EMAIL PROTECTED] wrote:
Steven Toth wrote:
The ts_bus_ctrl function pointer / callback is already in the mainline,
check dvb_frontend.c for more details. You shouldn't need a patch from me.
ACK, should be enough to do this kind of locking.
Furthermore, with this callback, the dvb_frontend_active() routine from
'[linux-dvb] [PATCH] function for checking if the dvb framework is idle'
is not required at all. The callback is aware whether the frontend is
running or not...
As far as I've seen the callback will be called as soon as the device
gets closed, even though the thread might still be spinning in the
background and the subsystem might still access DVB components, this
is why dvb_frontend_active is still needed.
Closing the devicenode and that callback doesn't mean that the device is idle.
Ok, this should be fixed. What about this patch:
diff -r dd58780b6fb4 linux/drivers/media/dvb/dvb-core/dvb_frontend.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Thu Aug 09 16:30:39
2007 +0200
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Fri Aug 17 20:07:28
2007 +0200
@@ -596,6 +596,10 @@ restart:
mb();
dvb_frontend_wakeup(fe);
+
+ if (fe-ops.ts_bus_ctrl)
+ fe-ops.ts_bus_ctrl (fe, 0);
+
return 0;
}
@@ -1101,9 +1105,10 @@ static int dvb_frontend_release(struct i
if ((file-f_flags O_ACCMODE) != O_RDONLY)
fepriv-release_jiffies = jiffies;
-
- if (fe-ops.ts_bus_ctrl)
- fe-ops.ts_bus_ctrl (fe, 0);
+ else {
+ if (fe-ops.ts_bus_ctrl)
+ fe-ops.ts_bus_ctrl (fe, 0);
+ }
ret = dvb_generic_release (inode, file);
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] [PATCH] add device node locking possibility to dvbcore
Markus Rechberger wrote:
On 8/17/07, Oliver Endriss [EMAIL PROTECTED] wrote:
Markus Rechberger wrote:
On 8/17/07, Oliver Endriss [EMAIL PROTECTED] wrote:
Steven Toth wrote:
The ts_bus_ctrl function pointer / callback is already in the
mainline,
check dvb_frontend.c for more details. You shouldn't need a patch from
me.
ACK, should be enough to do this kind of locking.
Furthermore, with this callback, the dvb_frontend_active() routine from
'[linux-dvb] [PATCH] function for checking if the dvb framework is idle'
is not required at all. The callback is aware whether the frontend is
running or not...
As far as I've seen the callback will be called as soon as the device
gets closed, even though the thread might still be spinning in the
background and the subsystem might still access DVB components, this
is why dvb_frontend_active is still needed.
Closing the devicenode and that callback doesn't mean that the device is
idle.
Ok, this should be fixed. What about this patch:
diff -r dd58780b6fb4 linux/drivers/media/dvb/dvb-core/dvb_frontend.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Thu Aug 09
16:30:39
2007 +0200
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Fri Aug 17
20:07:28
2007 +0200
@@ -596,6 +596,10 @@ restart:
mb();
dvb_frontend_wakeup(fe);
+
+ if (fe-ops.ts_bus_ctrl)
+ fe-ops.ts_bus_ctrl (fe, 0);
+
return 0;
}
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.
@@ -1101,9 +1105,10 @@ static int dvb_frontend_release(struct i
if ((file-f_flags O_ACCMODE) != O_RDONLY)
fepriv-release_jiffies = jiffies;
-
- if (fe-ops.ts_bus_ctrl)
- fe-ops.ts_bus_ctrl (fe, 0);
+ else {
+ if (fe-ops.ts_bus_ctrl)
+ fe-ops.ts_bus_ctrl (fe, 0);
+ }
can you explain this? to me it doesn't look right. Before it always
called ts_bus_ctrl and afterwards it has a dependency to the access
mode bits?
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
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] [patch] dvb_net hotplugging support
Trent Piepho wrote: On Fri, 17 Aug 2007, Oliver Endriss wrote: Markus Rechberger wrote: Since this didn't get commented here, Trent did that patch already 2 months ago but it's not included yet. So I recommend to include his patch. http://article.gmane.org/gmane.linux.kernel/543689 Acked-by: Markus Rechberger [EMAIL PROTECTED] Are you talking about this tiny patch? struct dvb_net *dvbnet = dvbdev-priv; - if (!dvbdev) - return -ENODEV; If yes, Acked-by: Oliver Endriss [EMAIL PROTECTED] Btw, why is this patch important? Basically it doesn't change anything. It checks if dvbdev is NULL after dvbdev already been used. Coverity spots this as a programming mistake (which it is), and Adrian Bunk posts patches to fix it. Sure, but the patch does exactly the same. It's just hidden behind a function call... @Mauro: This patch simply replaces a code block by a function call. The function does exactly the same as the code block did. It's safe to apply this patch. 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
e9hack wrote: Oliver Endriss schrieb: Jukka Pirinen wrote: As workaround I commented out initialisation of CI interface, that's not a problem because I don't have CI. diff budget-av.c.orig budget-av.c 1175c1175 ciintf_init(budget_av); --- //ciintf_init(budget_av); Could you please try to find out, why the CI thread is causing high load? You might start checking the values of ca-delay and ca-wakeup before wait_event_interruptible_timeout(). Sorry, I can't do this. I don't have budget-av hardware. It may be a problem of saa7146_wait_for_debi_done(). Without a CI/CAM, every debi read/write request ends with an error. In this case, SPCI_DEBI_S will never go low. Yep, this might be a problem. But it is surprising that this issue was never detected before. If DEBI_S ever goes high, it will never be reset. Afaics there is no direct way to reset this bit. (A new debi command should reset it, though.) Most of the debi requests are done with an spinlock held. None of the debiread/write accesses in budget-av uses locks, which is probably a bug. See the other thread. Saa7146_wait_for_debi_done() polls for 250msec the PSR. Possible, this is the reason for the high load. Usually, saa7146_wait_for_debi_done() can bail out earlier, if SPCI_DEBI_E is set. Some debiread/write calls in budget-av use busy-waiting. For testing it might be worth to set the last parameter of the debiread/write calls to 1 (nobusyloop). saa7146_wait_for_debi_done() is also used by the TT-FF cards. During the booting of the ARM, this cards need the timeout/wait after a debi error. Could you please explain why the FF card needs this timeout? 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] New Revision of KNC1 DVB-S Plus 1894:0015
Johannes Deisenhofer wrote: Oliver Endriss wrote: Johannes Deisenhofer wrote: Hi, I have a bunch of KNC1 DVB-S Plus Cards, with Subsystem ID 1894:0015. There are 'Plus' cards, with Phillips SD1878 Tuner and Analog Inputs. (Picture at http://www.vdr-wiki.de/wiki/index.php/Bild:Knc1splusx4.jpg) Is 'KNC1 DVB-S plus X4' the correct name of this card? According to your patch the name is 'SUBID_DVBS_TV_STAR_PLUS'. Hm, difficult to tell. It's called TV Station Plus on the box, but is different from the old 'TV Station Plus'. 'X4' is written on the board (see photo). The windows driver's .ini-File calls it 'DVBS+ X4' Technically, it's more in line with the TV Star cards (same tuner). But I'll gladly leave the taxonomic decisions to the maintainer. Then let's call this baby 'TV Station Plus X4'. ;-) Besides the analog input, these seem to be identical to the TV Star Cards from KNC1. Adding the PCI Ids is easy, but: Can anybody advise me how I can find out if my card needs to be added to this list of IDs? It's a plus card, after all. Do I need to test with a CA adapter? Would be nice (if you have a CI/CAM). I could probably find one, if there's a chance it has something to do with it. Simply try whether it works without setting GPIO3. If not, try with GPIO3 set to high. Been there, done that. Works both ways. Iirc GPIO3 has something to do with the initialisation of the CI/CAM. So it would be nice if you could verify that. If it works both ways, we should not touch GPIO3. 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] Suspend/Resume support for budget-av
Marko Ristola wrote: I did for the Mantis branch a working solution for mem and disk cases. I haven't tested standby yet, but I think that it should be easy to extend if it doesn't work yet. I used linux/Documentation/power/*.txt while trying to understand how to implement suspend/resume. On my opinion, the easiest way to make standby+mem+disk work, is to implement suspend() so, that you assume that you might lose the power if the source transition is D0. If the source transition state is another one, you just turn some power off, but don't touch the saved state that resume() needs. (My implementation doesn't handle source transition at all now, because of my limited time.) Then you must implement resume() so, that it assumes, that you are recovering from a power loss. You might try to optimize resume() by checking from the device or from some previous kernel state, whether the device has actually lost it's power or not. My Mantis suspend/resume altered too many files, and thus it isn't final yet, but it is a working although not perfect version. In Linux code, there is a more simple PCI suspend/resume implementation in linux/drivers/pci/pci-driver.c. pci_device_suspend(): this does a very simple and basic PCI suspend operation. pci_default_resume(): this does a very simple and basic PCI resume operation. So I will try to learn from them some day to lessen changes in mantis_pci.c. My personal idea for the responsibilities is that: pci_save_state() and pci_restore_state() and other function calls found in pci-driver.c will handle saving and restoring PCI state, although I absolute must copy them into mantis_pci.c. Then on resume, I have to restore non-pci states, I mean those that aren't restored by pci_restore_state(), pci_set_master() and such. In Mantis there is according to Manu at least tuner power setting and retuning. I don't know the working and optimally small solution yet that Manu requires: there is still testing to be done for me in Mantis. With a very small understanding, I have been able to implement a working patch though. So I'd suggest for you to check out drivers/pci/pci-driver.c first to implement similar PCI functionality into budget-av. That might fix S2MEM and S2DISK. Or then there is still something more that has to be done. With my implementation I can use Kaffeine so, that after S2DISK, Kaffeine will continue showing the channel that it showed before. Kaffeine doesn't have to retune or restart DMA transfer. So only some frames were lost. Kaffeine didn't work properly with USB based sound output, and thus I needed motherboard internal sound output for the tests. Thanks for your response. Meanwhile I had a look at Documentation/power and did more tests. For a proper suspend/restore implementation there is much more to be done. The state of the saa7146 must be saved/restored, which requires more than a few hours of work (and testing!). I put it on my todo list. Is there any way to find out the power state the system tries to enter (standby/mem/disk)? For now, I could add support for standby mode and deny any attempt to enter mem or disk supend mode. Better than nothing... 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] budget-av/CI-interface with SMP
Julian Scheel wrote: Am Donnerstag 16 August 2007 13:12 schrieb Julian Scheel: Am Donnerstag 09 August 2007 20:34 schrieb Oliver Endriss: Well, that's not surprising. If you set uselocks=1, ttpci_budget_debiread/write must not sleep, i.e. you have to set nobusyloop=0. Does it work now? Nevertheless I don't like busy looping with interrupts disabled. AFAICS the budget_debi routines are never called from interrupt context, so it should be sufficient to use spin_[un]lock_bh() instead of spin_[un]lock_irq_save(). Could you please try this? When I switch from irq-lock to bh-lock while keeping uselocks = 1, the error changes: BUG: scheduling while atomic: kdvb-ca-0:0/0x0101/28258 [c03c51a6] __sched_text_start+0x56/0x7a4 [c012c4bd] lock_timer_base+0x15/0x2f [c012c5c9] __mod_timer+0x94/0x9e [c03c6054] schedule_timeout+0x70/0x8d [c03c5869] __sched_text_start+0x719/0x7a4 [c012bbfd] process_timeout+0x0/0x5 [c012c5e0] msleep+0xd/0x12 [e0b5fe23] saa7146_wait_for_debi_done+0xda/0xec [saa7146] [e0b7378c] ttpci_budget_debiread+0x44/0xce [budget_core] [e0c0528b] ciintf_poll_slot_status+0x99/0x146 [budget_av] [e0c432d0] dvb_ca_en50221_check_camstatus+0x37/0xae [dvb_core] [e0c44493] dvb_ca_en50221_thread+0x1c7/0xb24 [dvb_core] [c0134be4] autoremove_wake_function+0x0/0x35 [c012deb4] do_notify_parent+0x155/0x160 [c011d46b] deactivate_task+0x19/0x23 [c016071f] __fput+0x112/0x13c [c0125b8f] put_files_struct+0x64/0xa7 [c0127072] do_exit+0x6a9/0x6ad [c03c8a61] do_page_fault+0x277/0x525 [c03c9612] kprobe_flush_task+0x4b/0x80 [c012118f] schedule_tail+0x4f/0x87 [c0103d46] ret_from_fork+0x6/0x1c [e0c442cc] dvb_ca_en50221_thread+0x0/0xb24 [dvb_core] [c0104a37] kernel_thread_helper+0x7/0x10 === Same problem as before: Must not sleep within spinlock-ed code. If I disable nobusyloop the errors are gone. I will check if the CI-module keeps working properly. If I disable nobusyloop the system becomes unresponsive after a while without CAM plugged. Does the machine freeze completely? No error messages on the console? Does it work with CAM plugged, or does it freeze, too? Please post the patch you are currently using. 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
Jukka Pirinen wrote: As workaround I commented out initialisation of CI interface, that's not a problem because I don't have CI. diff budget-av.c.orig budget-av.c 1175c1175 ciintf_init(budget_av); --- //ciintf_init(budget_av); Could you please try to find out, why the CI thread is causing high load? You might start checking the values of ca-delay and ca-wakeup before wait_event_interruptible_timeout(). Sorry, I can't do this. I don't have budget-av hardware. 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] New Revision of KNC1 DVB-S Plus 1894:0015
Johannes Deisenhofer wrote:
Hi,
I have a bunch of KNC1 DVB-S Plus Cards, with Subsystem ID 1894:0015.
There are 'Plus' cards, with Phillips SD1878 Tuner and Analog Inputs.
(Picture at http://www.vdr-wiki.de/wiki/index.php/Bild:Knc1splusx4.jpg)
Is 'KNC1 DVB-S plus X4' the correct name of this card?
According to your patch the name is 'SUBID_DVBS_TV_STAR_PLUS'.
Besides the analog input, these seem to be identical to the TV Star
Cards from KNC1. Adding the PCI Ids is easy, but:
Can anybody advise me how I can find out if my card needs to be added to
this list of IDs? It's a plus card, after all. Do I need to test with a
CA adapter?
Would be nice (if you have a CI/CAM).
What's different if I set / don't set the GPIO-Pin?
From budget-av.c, line 928:
/* additional setup necessary for the PLUS cards */
switch (saa-pci-subsystem_device) {
case SUBID_DVBS_KNC1_PLUS:
case SUBID_DVBC_KNC1_PLUS:
case SUBID_DVBT_KNC1_PLUS:
case SUBID_DVBS_TV_STAR_PLUS:
case SUBID_DVBC_EASYWATCH:
case SUBID_DVBC_KNC1_PLUS_MK3:
saa7146_setgpio(saa, 3, SAA7146_GPIO_OUTHI);
break;
}
Simply try whether it works without setting GPIO3.
If not, try with GPIO3 set to high.
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] [PATCH] add device node locking possibility to dvbcore
Steven Toth wrote: Steven Toth wrote: Markus Rechberger wrote: On 8/9/07, Steven Toth [EMAIL PROTECTED] wrote: Markus Rechberger wrote: On 8/9/07, Steven Toth [EMAIL PROTECTED] wrote: Markus Rechberger wrote: Following patch adds a rather primitive way to temporary lock dvb devicenodes, this can be useful for hybrid devices which use the video4linux framework for the analogue TV part and the dvb framework for digital TV if only one mode can be accessed at a time. Signed-off-by: Markus Rechberger [EMAIL PROTECTED] Call me dumb but I don't understand how this patch helps v4l devices. :) Allocation/management of a single card resource doesn't belong inside the dvb framework, these answers need to come from the bridge-frameworks (via callbacks from dvb-core or the analog equivalent) who are better placed to make the decision about hybrid tuners, bus capacity or allocation, in use devices. As a working example, I added similar support in my older HVR3000 tree where two frontends share a single transport bus. The code is old but it demonstrates a solution, much the my earlier patches for shared DVB/Blackbird boards also. I understand how this patch helps the current dvb tree, it stops multiple people opening a device but that's it. ... Or, maybe I've just missed to point. Hi Steve, the bridge framework triggers locking these filehandles. http://mcentral.de/hg/~mrec/v4l-dvb-experimental/file/c0817d73a2a9/linux/drivers/media/video/em28xx/em28xx-video.c line 434 this locks the dvb nodes if someone tries to open the v4l devicenode, it first checks if there's still something active at the DVB side. http://mcentral.de/hg/~mrec/v4l-dvb-experimental/file/f9f3e6bdd6fc/linux/drivers/media/video/em28xx/em2880-dvb.c Line 471 - 484 if this would go into the dvb core we'd have a callback for locking the device nodes. Your comment about lines 471-484 make sense, but that code is not referenced via a callback (that I can see in the DVB patch) ... which is what I expected to see. To do this cleanly in the dvb-core (or any v4l-core) I suggest requires callbacks into the bridge-frameworks and I didn't see those callbacks clearly defined in either your original patch, or your follow up patches. I was pretty sure I did something similar for the DVB/MpegEncoder shared bus support. Have you seen this? http://linuxtv.org/hg/~stoth/hvr3000/rev/4b846f1d939b Or more importantly this: http://linuxtv.org/hg/~stoth/hvr3000/rev/a619436699cc Can we just re-use that? Since I don't see any move forward from anyone again, can you extract that locking callback and submit it independently? I can work around the issue that the dvb core still tries to access DVB components after a device has been closed, although you might have to verify that issue within your drivers too. Sure, I'll prepare a patch later this evening. The ts_bus_ctrl function pointer / callback is already in the mainline, check dvb_frontend.c for more details. You shouldn't need a patch from me. ACK, should be enough to do this kind of locking. Furthermore, with this callback, the dvb_frontend_active() routine from '[linux-dvb] [PATCH] function for checking if the dvb framework is idle' is not required at all. The callback is aware whether the frontend is running or not... 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] [patch] dvb_net hotplugging support
Markus Rechberger wrote:
Since this didn't get commented here, Trent did that patch already 2
months ago but it's not included yet. So I recommend to include his
patch.
http://article.gmane.org/gmane.linux.kernel/543689
Acked-by: Markus Rechberger [EMAIL PROTECTED]
Are you talking about this tiny patch?
--- a/linux/drivers/media/dvb/dvb-core/dvb_net.cFri Jun 08 08:58:41
2007 -0300
+++ b/linux/drivers/media/dvb/dvb-core/dvb_net.cFri Jun 15 15:34:08
2007 -0700
at at -1502,18 +1502,9 at at static int dvb_net_close(struct
inode *i
struct dvb_device *dvbdev = file-private_data;
struct dvb_net *dvbnet = dvbdev-priv;
- if (!dvbdev)
- return -ENODEV;
-
- if ((file-f_flags O_ACCMODE) == O_RDONLY) {
- dvbdev-readers++;
- } else {
- dvbdev-writers++;
- }
-
- dvbdev-users++;
-
- if(dvbdev-users == 1 dvbnet-exit==1) {
+ dvb_generic_release(inode, file);
+
+ if(dvbdev-users == 1 dvbnet-exit == 1) {
fops_put(file-f_op);
file-f_op = NULL;
wake_up(dvbdev-wait_queue);
If yes,
Acked-by: Oliver Endriss [EMAIL PROTECTED]
Btw, why is this patch important? Basically it doesn't change anything.
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] Suspend/Resume support for budget-av
Julian Scheel wrote:
Oliver Endriss schrieb:
Julian Scheel wrote:
Attached is a patch with adds full support for suspend/resume in
budget-av.
Actually only the CI interface needs to be reinitialised as all the tuner
stuff gets reinitialised at the next tuning-process anyway.
So this patch should be ready to go pretty straightforward into head.
Please post the sub-system ids of the cards you tested and which power
states you tested.
Going to look up the IDs later, when I have access to my dev-system.
But it should be all current KNC DVB-C and DVB-S cards.
diff -r c45e373bbca3 linux/drivers/media/common/saa7146_core.c
--- a/linux/drivers/media/common/saa7146_core.c Sat Jul 28 00:06:44 2007
-0300
+++ b/linux/drivers/media/common/saa7146_core.c Tue Aug 07 23:22:54 2007
+0200
@@ -515,6 +515,28 @@ static void saa7146_remove_one(struct pc
saa7146_num--;
}
+static int saa7146_suspend(struct pci_dev *pdev)
+{
+ struct saa7146_dev* dev = pci_get_drvdata(pdev);
+ DEB_EE((dev:%p\n,dev));
+ int err;
+
+ err = dev-ext-suspend(dev);
^
Causes an oops if the card driver did not set the suspend hook.
Fix:
int err = -EBUSY;
if (dev-ext-suspend)
err = dev-ext-suspend(dev);
Agreed (c:
+
+ return err;
+}
+
+static int saa7146_resume(struct pci_dev *pdev)
+{
+ struct saa7146_dev* dev = pci_get_drvdata(pdev);
+ DEB_EE((dev:%p\n,dev));
+ int err;
+
+ err = dev-ext-resume(dev);
ditto
IMO this patch can only work with S1 state. Higher states turn off PCI
power and require re-initialization of saa7146, demod, tuner etc.
See other drivers which fully implement suspend/resume.
Works perfectly fine with S3-state for me. Actually S3 always worked
fine, only ci interface did not work anymore after S3, that is fixed
with this patch.
Hm, I did some tests with budget.c:
- echo standby /sys/power/state works
- echo mem /sys/power/state does not work!
- echo disk /sys/power/state does not work!
It works if the PCI bus stays 'on', i.e. the card is not powered-off.
So there is much more to be done if we want to support power states
properly.
Btw, could you test if the CI works without reinitialisation if you
apply the attached patch? I can't test it. Without this patch the kernel
thread will die and the CI does not work anymore...
CU
Oliver
--
VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/
diff -r 600876f4508f linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c Thu Aug 09 07:41:16 2007 +0200
+++ b/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c Sun Aug 12 14:39:07 2007 +0200
@@ -38,8 +38,15 @@
#include linux/spinlock.h
#include linux/sched.h
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
+#include linux/suspend.h
+#else
+#include linux/freezer.h
+#endif
+
#include dvb_ca_en50221.h
#include dvb_ringbuffer.h
+#include compat.h
static int dvb_ca_en50221_debug;
@@ -1002,6 +1009,8 @@ static int dvb_ca_en50221_thread(void *d
/* choose the correct initial delay */
dvb_ca_en50221_thread_update_delay(ca);
+ set_freezable();
+
/* main loop */
while (!ca-exit) {
/* sleep for a bit */
@@ -1009,6 +1018,8 @@ static int dvb_ca_en50221_thread(void *d
flags = wait_event_interruptible_timeout(ca-thread_queue,
dvb_ca_en50221_thread_should_wakeup(ca),
ca-delay);
+ if (try_to_freeze())
+continue;
if ((flags == -ERESTARTSYS) || ca-exit) {
/* got signal or quitting */
break;
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Michael Krufky wrote: Oliver Endriss wrote: Manu Abraham wrote: On 8/6/07, Michael Krufky [EMAIL PROTECTED] wrote: Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? Ideally, what's provided by the demod and not the tuner max/min. The tuners max/min should be checked by the demod on setting params. The upper/lower limits in the demodulator drivers, came from the concept of a frontend as a whole. Independant bounds do not make sense (except internally -- It is the demod driver that which sets parameters for the tuner. The external world doesn't need to know what's the limit of the tuner, but only of the frontend as a whole). Ideally, the demodulator should just demodulate only. There are some cases, there are some cases which are not. Ok, I'm trying to put all pieces together: There might be cases where demod and tuner have different limits. So FE_GET_INFO and dvb_frontend_check_parameters() should use the 'smallest common bandwidth': freq_min = max(fe-ops.info.frequency_min, fe-ops.tuner_ops.info.frequency_min); if (fe-ops.info.frequency_max == 0) freq_max = fe-ops.tuner_ops.info.frequency_max; else if (fe-ops.tuner_ops.info.frequency_max == 0) freq_max = fe-ops.info.frequency_max; else freq_max = min(fe-ops.info.frequency_max, fe-ops.tuner_ops.info.frequency_max); if (freq_min == 0 || freq_max == 0) printk(KERN_WARNING frequency limits undefined - please fix the driver\n); Conclusions: - A tuner-only driver must set fe-ops.tuner_ops.info. - Monolithic drivers must set fe-ops.tuner_ops.info or fe-ops.info (or both). I apologize for my delayed response -- I had to leave town unexpectedly. No problem. The above is OK with me. As I understand it, we cannot remove fe-ops.info.frequency_max|min because it is part of the userspace API. I wasn't thinking about that fact when I wrote my last email in this thread. We should keep this in mind, for whenever the time comes that we do have to break API compat. Basically, the internal data structures don't have to be the same as the external API data structures. The GET_INFO ioctl might collect its data from anywhere... I think we should postpone cleaning-up the frontend data until multiproto has been merged. It will add more compatibility stuff, so it might be worth cleaning up these things afterwards. For now I have committed Hartmut's patch and the fix above. 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
Sigmund Augdal wrote: On Tuesday 17 July 2007 07:45, Oliver Endriss 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. I've tried this patch on a box running 2.6.20 now for about a day and has not yet seen any i2c timeouts with it. I have tried to stress the i2c bus a bit by starting and stopping capture, retuning and browsing the MMI menus of the CAM quite a lot. I did however not see any pattern in when the i2c timeouts happened before applying the patch, so I can't possitivly confirm they are all gone. Ok, patch committed with minor modifications. 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] budget-av/CI-interface with SMP
Julian Scheel wrote: Oliver Endriss schrieb: Julian Scheel wrote: Attached is a patch which fixes an issue which I see with budget-av based cards using libdvben50221 based programs. After some time (sometimes just a few minutes, sometimes hours) the stack breaks with error -2 or -3 and won't recover until the modules are reloaded. Please post the error log. This does not happen anymore with this patch, but if no CI-interface is connected this patch floads the syslog with weird error-messages of which I have no idea why they are shown. Please post a log of these error messages. Thanks, Oliver Sure, this is the error that loops all over: BUG: scheduling while atomic: kdvb-ca-0:0/0x0001/3030 [c03c51a6] __sched_text_start+0x56/0x7a4 [c012c4bd] lock_timer_base+0x15/0x2f [c012c5c9] __mod_timer+0x94/0x9e [c03c6054] schedule_timeout+0x70/0x8d [c03c5869] __sched_text_start+0x719/0x7a4 [c012bbfd] process_timeout+0x0/0x5 [c012c5e0] msleep+0xd/0x12 [e0bfbe23] saa7146_wait_for_debi_done+0xda/0xec [saa7146] [e0be778f] ttpci_budget_debiread+0x47/0xd6 [budget_core] [e0c3728b] ciintf_poll_slot_status+0x99/0x146 [budget_av] [e0c1d2d0] dvb_ca_en50221_check_camstatus+0x37/0xae [dvb_core] [e0c1e493] dvb_ca_en50221_thread+0x1c7/0xb24 [dvb_core] [c0134be4] autoremove_wake_function+0x0/0x35 [c0127072] do_exit+0x6a9/0x6ad [c03c8a61] do_page_fault+0x277/0x525 [c03c9612] kprobe_flush_task+0x4b/0x80 [c012118f] schedule_tail+0x4f/0x87 [c0103d46] ret_from_fork+0x6/0x1c [e0c1e2cc] dvb_ca_en50221_thread+0x0/0xb24 [dvb_core] [c0104a37] kernel_thread_helper+0x7/0x10 === Well, that's not surprising. If you set uselocks=1, ttpci_budget_debiread/write must not sleep, i.e. you have to set nobusyloop=0. Does it work now? Nevertheless I don't like busy looping with interrupts disabled. AFAICS the budget_debi routines are never called from interrupt context, so it should be sufficient to use spin_[un]lock_bh() instead of spin_[un]lock_irq_save(). Could you please try this? 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] Suspend/Resume support for budget-av
Julian Scheel wrote:
Attached is a patch with adds full support for suspend/resume in budget-av.
Actually only the CI interface needs to be reinitialised as all the tuner
stuff gets reinitialised at the next tuning-process anyway.
So this patch should be ready to go pretty straightforward into head.
Please post the sub-system ids of the cards you tested and which power
states you tested.
diff -r c45e373bbca3 linux/drivers/media/common/saa7146_core.c
--- a/linux/drivers/media/common/saa7146_core.c Sat Jul 28 00:06:44 2007 -0300
+++ b/linux/drivers/media/common/saa7146_core.c Tue Aug 07 23:22:54 2007 +0200
@@ -515,6 +515,28 @@ static void saa7146_remove_one(struct pc
saa7146_num--;
}
+static int saa7146_suspend(struct pci_dev *pdev)
+{
+ struct saa7146_dev* dev = pci_get_drvdata(pdev);
+ DEB_EE((dev:%p\n,dev));
+ int err;
+
+ err = dev-ext-suspend(dev);
^
Causes an oops if the card driver did not set the suspend hook.
Fix:
int err = -EBUSY;
if (dev-ext-suspend)
err = dev-ext-suspend(dev);
+
+ return err;
+}
+
+static int saa7146_resume(struct pci_dev *pdev)
+{
+ struct saa7146_dev* dev = pci_get_drvdata(pdev);
+ DEB_EE((dev:%p\n,dev));
+ int err;
+
+ err = dev-ext-resume(dev);
ditto
IMO this patch can only work with S1 state. Higher states turn off PCI
power and require re-initialization of saa7146, demod, tuner etc.
See other drivers which fully implement suspend/resume.
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] budget-av/CI-interface with SMP
Julian Scheel wrote: Attached is a patch which fixes an issue which I see with budget-av based cards using libdvben50221 based programs. After some time (sometimes just a few minutes, sometimes hours) the stack breaks with error -2 or -3 and won't recover until the modules are reloaded. Please post the error log. This does not happen anymore with this patch, but if no CI-interface is connected this patch floads the syslog with weird error-messages of which I have no idea why they are shown. Please post a log of these error messages. Thanks, 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] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Manu Abraham wrote: On 8/6/07, Michael Krufky [EMAIL PROTECTED] wrote: Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? Ideally, what's provided by the demod and not the tuner max/min. The tuners max/min should be checked by the demod on setting params. The upper/lower limits in the demodulator drivers, came from the concept of a frontend as a whole. Independant bounds do not make sense (except internally -- It is the demod driver that which sets parameters for the tuner. The external world doesn't need to know what's the limit of the tuner, but only of the frontend as a whole). Ideally, the demodulator should just demodulate only. There are some cases, there are some cases which are not. Ok, I'm trying to put all pieces together: There might be cases where demod and tuner have different limits. So FE_GET_INFO and dvb_frontend_check_parameters() should use the 'smallest common bandwidth': freq_min = max(fe-ops.info.frequency_min, fe-ops.tuner_ops.info.frequency_min); if (fe-ops.info.frequency_max == 0) freq_max = fe-ops.tuner_ops.info.frequency_max; else if (fe-ops.tuner_ops.info.frequency_max == 0) freq_max = fe-ops.info.frequency_max; else freq_max = min(fe-ops.info.frequency_max, fe-ops.tuner_ops.info.frequency_max); if (freq_min == 0 || freq_max == 0) printk(KERN_WARNING frequency limits undefined - please fix the driver\n); Conclusions: - A tuner-only driver must set fe-ops.tuner_ops.info. - Monolithic drivers must set fe-ops.tuner_ops.info or fe-ops.info (or both). Ok? 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] frequency out of range - Problems
Michael Krufky wrote:
Manu Abraham wrote:
On 8/6/07, Lars Buerding [EMAIL PROTECTED] wrote:
Hello Manu,
I am getting these messages using the latest available tip-version
(v4l-dvb-5bb1af77fdc5).
--
Aug 6 07:07:17 gwmuc kernel: DVB: frontend 0 frequency 151 out of
range (95..140)
Aug 6 07:08:05 gwmuc kernel: DVB: frontend 0 frequency 1958000 out of
range (95..140)
--
In frontends/tda8083.c
Look for this:
446 .frequency_min = 95, /* FIXME:
guessed! */
447 .frequency_max = 140,/* FIXME:
guessed! */
change to line: #447 to
.frequency_max = 215,
This should fix your problem.
Manu
I did that and it looks good - at least I can switch to the channels
again and can grab a picture inside vdradmin, I am a bit too far away
from my VDR currently :)
N' joy :)
Manu,
Do you have a spec for that demod? If so, would you kindly update the driver
so
that users don't have to worry about this issue?
According to the crippled datasheet, a symbol rate from 12..30 MSym/s
should be correct for the TDA8083.
The Grundig 29504-451 tuner uses the TDA8060 down-converter, which has a
frequency range from 920..2200MHz.
So the attached patch should fix the range issues. Ok?
CU
Oliver
-
VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/
diff -r 8f9147c3bacd linux/drivers/media/dvb/frontends/tda8083.c
--- a/linux/drivers/media/dvb/frontends/tda8083.c Wed Aug 01 12:14:44 2007 -0300
+++ b/linux/drivers/media/dvb/frontends/tda8083.c Mon Aug 06 18:06:09 2007 +0200
@@ -443,12 +443,12 @@ static struct dvb_frontend_ops tda8083_o
.info = {
.name = Philips TDA8083 DVB-S,
.type = FE_QPSK,
- .frequency_min = 95, /* FIXME: guessed! */
- .frequency_max = 140,/* FIXME: guessed! */
+ .frequency_min = 92, /* TDA8060 */
+ .frequency_max = 220,/* TDA8060 */
.frequency_stepsize = 125, /* kHz for QPSK frontends */
/* .frequency_tolerance = ???,*/
- .symbol_rate_min = 100, /* FIXME: guessed! */
- .symbol_rate_max = 4500, /* FIXME: guessed! */
+ .symbol_rate_min = 1200,
+ .symbol_rate_max = 3000,
/* .symbol_rate_tolerance = ???,*/
.caps = FE_CAN_INVERSION_AUTO |
FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 | FE_CAN_FEC_3_4 |
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 support
Steven Toth wrote: ... But were a way off, perhaps months from seeing multiproto accept in v4l-dvb hg. Why? I think it's time to get multiproto into the main tree. We should review the API and dvb core changes asap. For me the API looks fine except for the modified FE_GET_EVENT ioctl, which is not backward compatible. When this issue has been fixed. there are no major problems afaics. 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] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Michael Krufky wrote: Oliver Endriss wrote: Michael Krufky wrote: e9hack wrote: Hi, the min frequencies of the DVB-C frontends are wrong. In Europe, the center frequency of the lowest channel is 50.5MHz and not 51MHz. All known cards with the stv0297/tda0002x/ves1820 frontend are able to tune to this frequency. I've changed the range to the lowest channel - 1/2 bandwidth and the highest channel + 1/2 bandwidth. For the design of the dvb driver, the frequency ranges must be part of the tuner and not of the frontend itself. The same frontend may be used for different tuners. The attached patch does only fix the ranges and not the design. Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? Hm, I was not aware that there is another info.frequency_min|max in tuner_ops. :-( Do we need both of them? I think it's most appropriate to keep tuner_ops.info.frequency_min|max , since it is the tuner that we're talking about. If the demodulator itself does not have such limitations, then we should not have such a field in the demod ops.info section. I believe that this is leftover from before Andrew's original dvb tuner refactoring. It is an API issue: FE_GET_INFO returns fe-ops.info, so we cannot easily drop this field. What about modifying dvb_pll_attach to override fe-ops.info.frequency? 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] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Michael Krufky wrote: Trent Piepho wrote: On Mon, 6 Aug 2007, e9hack wrote: Michael Krufky schrieb: Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? I didn't see the ranges from the tuner, because the dvb-c drivers don't use the pll framework. They have very simple tuning functions only. We should use both values. One part may be more restrictive than the other one. Most demodulators don't have frequency ranges. They just take whatever the tuner gives them at a fixed intermediate frequency. It's really the tuner that has the frequency range. Agreed. I think it would make more sense for the demodulator drivers to fill fe-ops.info.frequency_min|max using fe-ops.tuner_ops.info.frequency_min|max. A frontend driver that doesn't use a separate tuner driver (like DST) would set the fe-ops.info.frequency_min|max directly. Afaics the demod driver cannot fill fe-ops.info.frequency_min|max using fe-ops.tuner_ops.info.frequency_min|max, because the tuner driver will be attached _after_ the demod driver (see budget-av.c for example). The way I see it, the demod driver that doesn't have a separate tuner driver should just go ahead and fill ops.tuner_ops.info.frequency_min|max , because otherwise those fields will be there anyway, just remaining empty. Those structures are not pointers, and we should always be able to rely on their presence. There is no need for BOTH ops.info.frequency_min|max AND ops.tuner_ops.info.frequency_min|max The following drivers set ops.tuner_ops.info.frequency_min|max: dvb-pll, mt2060, qt1010, tda826x, tda827x, tua6100. All other drivers use ops.info.frequency_min|max. What about this: dvb_frontend.c shall use ops.tuner_ops.info.frequency_min|max if non-zero. Otherwise it would continue to use ops.info.frequency_min|max. 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] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Michael Krufky wrote: Oliver Endriss wrote: Michael Krufky wrote: Trent Piepho wrote: On Mon, 6 Aug 2007, e9hack wrote: Michael Krufky schrieb: Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? I didn't see the ranges from the tuner, because the dvb-c drivers don't use the pll framework. They have very simple tuning functions only. We should use both values. One part may be more restrictive than the other one. Most demodulators don't have frequency ranges. They just take whatever the tuner gives them at a fixed intermediate frequency. It's really the tuner that has the frequency range. Agreed. I think it would make more sense for the demodulator drivers to fill fe-ops.info.frequency_min|max using fe-ops.tuner_ops.info.frequency_min|max. A frontend driver that doesn't use a separate tuner driver (like DST) would set the fe-ops.info.frequency_min|max directly. Afaics the demod driver cannot fill fe-ops.info.frequency_min|max using fe-ops.tuner_ops.info.frequency_min|max, because the tuner driver will be attached _after_ the demod driver (see budget-av.c for example). The way I see it, the demod driver that doesn't have a separate tuner driver should just go ahead and fill ops.tuner_ops.info.frequency_min|max , because otherwise those fields will be there anyway, just remaining empty. Those structures are not pointers, and we should always be able to rely on their presence. There is no need for BOTH ops.info.frequency_min|max AND ops.tuner_ops.info.frequency_min|max The following drivers set ops.tuner_ops.info.frequency_min|max: dvb-pll, mt2060, qt1010, tda826x, tda827x, tua6100. All other drivers use ops.info.frequency_min|max. What about this: dvb_frontend.c shall use ops.tuner_ops.info.frequency_min|max if non-zero. Otherwise it would continue to use ops.info.frequency_min|max. That's fine with me... except I just don't see why we shouldn't just have the demod drivers that have the integrated tuning functionality just fill tuner_ops.info.frequency_max|min anyway. The point is, the structures will be present regardless of whether any tuner_ops are actually filled. This is an opportunity to remove the frequency_min|max from the demod ops.info structure, as we all agree that it is inappropriate there anyhow. If we do this, then we will have a standard across the board. That's fine if we agree that we have to touch most frontend drivers. If we choose to do that, we should remove ops.info.frequency_min|max, i.e. remove 'struct dvb_frontend_info' from 'struct frontend_ops' and add something like 'struct dvb_demod_info' instead. We must not modify 'struct dvb_frontend_info' because it is an API data structure. Afaics 'frequency_stepsize' can be substituted by 'frequency_step', but what should we do with 'frequency_tolerance'? 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] [PATCH] Fix the min/max frequencies of some DVB-C frontends
e9hack wrote: Currently, I'm missing something in the tuner modules (and I didn't ask for it). It isn't possible to wait for getting the pll lock. The tuning function of the TT-C2300 does wait. It isn't possible to switch the time constant of the loop filter after getting the lock. Usually, it is recommended for any pll chips. Have a look how I implemented that in the tda10086 driver (search for 'has_lock'). 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] Problems with SMP (i.e. dualcore) system: dvb-ttpci: warning: timeout waiting in LoadBitmap
Sven Mueller wrote: Oliver Endriss wrote on 01/08/2007 00:27: Sven Mueller wrote: Hi. I don't know which hardware interrupts those are mapped from/to and currently don't know how to find out. If you need any further data to give a helpful answer, don't hesitate to ask. Which firmware are you using? Most recent AFAICT (261f). Nope, the most recent firmware is http://linuxtv.org/downloads/firmware/dvb-ttpci-01.fw-2622 or the latest experimental firmware http://www.suse.de/~werner/test_av-f12623.tar.bz2 A log showing driver startup might be useful. Do you mean this? dvb-ttpci: gpioirq unknown type=0 len=0 dvb-ttpci: info @ card 1: firm f0240009, rtsl b0250018, vid 71010068, app 8000261f dvb-ttpci: firmware @ card 1 supports CI link layer interface dvb-ttpci: Crystal audio DAC @ card 1 detected dvb-ttpci: found av7110-0. Does OSD work fine before the error occurres? Yes Does the VDR recover if you wait some time (1 or 2 minutes) before you press the next key? Sometimes (if I interpret things correctly though, this is due to an internal watchdog in VDR triggering a restart, which now, on my system, includes module unload/reload due to my problems). With recent firmware VDR should recover _without_ emergency exit. You might also try whether this driver improves things: http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-refactoring/ Will take a look into that later once I find some time. One think fixed the problem for me, for now though: noapic nolapic on the kernel commandline (grub). Are you sure that this did not disable SMP? However the system runs stable in every other aspect, so it seems to me that enabling apic/lapic does something which the dvb_ttpci driver doesn't handle properly on SMP systems. There is no special handling for SMP or non-SMP systems. Of course there might be a bug which will only show up with SMP. :-( 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] Re : Professional trolls
manu wrote: Well for reading this list out of curiosity for a while (also I have a TT S-1500 CI that I plan to use soon ;-) I for sure am surprised by the amount of noise surrounding actual coding discussion. I have participated in another free software project and things were much smoother. I understand that some people will just not get along, but things sound really nasty sometimes here. Don't worry, this happens from time to time. It is a problem in the good old USENET, and there is the same problem in the Internet. Apparently we have to live with it. If you are really interested, look at the mailing list archives and you will see, when this started and who is responsible... Simply blacklist the offending mail addresses, and they will never bother you again. ;-) Meanwhile I have blacklisted 3 or 4 list users. And an ex-maintainer will enter my killfile soon, if he will not stop abusing this mailing list for his propaganda. This list was created for technical discussions and user support, not for frustrated egoists! 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
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. 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] Problems with SMP (i.e. dualcore) system: dvb-ttpci: warning: timeout waiting in LoadBitmap
Sven Mueller wrote: Hi. I'm running my vdr on an up-to-date (with respects to BIOS) ASUS mainboard P5VD2-X with an Intel Pentium DualCore E2160 (a 65Watts dualcore at 1800MHz). Kernel version is 2.6.18-4 (from Debian/ctvdr6). The system has two IDE disks (with DMA enabled of course) and both a budget (Nova-S) and a full featured (Nexus-S, rev. 1.5 IIRC) DVB-S PCI card. If I boot 2.6.18-4-486 (which is a non-SMP kernel so only one core is used), my vdr works perfectly nice. However, when I boot 2.6.18-4-686 or any other SMP kernel (self-built or not, with Debian/ctvdr patches or a stock kernel up to version 2.6.22, I tried everything apart from diving into the code myself), I get the error message quoted in the subject line (in syslog): kernel: dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1 And vdr seems to retry loading the Bitmap (as further messages of the kind appear until I kill vdr and remove+reload the DVB kernel modules). The error isn't 100% reproducible but usually occures when I try to open vdr's on-screen menu. Once the first message of that kind occures, vdr isn't responsible to keyboard/LIRC inputs anymore. Any ideas how to fix this problem? I would really love to be able to use both cores of my CPU and still have a working vdr. lspci -v output for the DVB-S cards: 04:04.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Siemens/Technotrend/Hauppauge DVB card rev1.3 or rev1.5 Flags: bus master, medium devsel, latency 32, IRQ 50 Memory at dfeff000 (32-bit, non-prefetchable) [size=512] 04:06.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Technotrend-Budget/Hauppauge WinTV-NOVA-S DVB card Flags: bus master, medium devsel, latency 32, IRQ 233 Memory at dfefe000 (32-bit, non-prefetchable) [size=512] /proc/interrupts|grep -E 'dvb|saa' says: 50: 1288508186 IO-APIC-level saa7146 (1) 233: 42658103 IO-APIC-level saa7146 (0) I don't know which hardware interrupts those are mapped from/to and currently don't know how to find out. If you need any further data to give a helpful answer, don't hesitate to ask. Which firmware are you using? A log showing driver startup might be useful. Does OSD work fine before the error occurres? Does the VDR recover if you wait some time (1 or 2 minutes) before you press the next key? You might also try whether this driver improves things: http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-refactoring/ 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
Stone wrote: 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 did not have any problems before this patch was introduced, but I have been using this patch since it was posted without any problems. These changes seem fine to me. Thank you for the feedback. 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] CAM problem with Cinergy/KNCONE DVB-C card
e9hack wrote: Hi, some people do report, that the CAM on a Cinergy/KNCONE DVB-C card doesn't work. They get the following log entries (repeated many times): budget-av: cam inserted A budget-av: cam inserted B dvb_ca adapter 1: DVB CAM detected and initialised successfully budget-av: cam ejected 3 ... It seems, that is never possible to read a control value of 0xff from address 0 or 1 of the CAM. The attached patch may fix this problem. I didn't test this patch by myself, because I don't need a CAM. If someone uses a Cinergy/KNCONE DVB-C/T/S card with a CAM, please test this patch. | ... ((result == 0xff) ((address 3) 2)) ... What does result 0xff mean? Btw, there is no such check in the budget-ci driver. 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] Hauppauge WinTV Nova-S-Plus - multiple read accesses impossible
Fabian Förg wrote: Fabian Förg wrote: Hello, in newer kernel releases multiple read accesses on the Hauppauge WinTV Nova-S-Plus are impossible. Thus, the command line femon is for example unable to open the DVB device when VDR is running: $ fuser -v /dev/dvb/adapter0/frontend0 USERPID ACCESS COMMAND /dev/dvb/adapter0/frontend0: myuser 5073 F vdr $ femon using '/dev/dvb/adapter0/frontend0' opening frontend failed: Device or resource busy I encounterd this issue with kernel 2.6.22.1 and the current Ubuntu feisty kernel (2.6.20.x). Older kernels allowed multiple accesses. However, I can't test which ones, because I replaced my system board some time ago, and older kernels don't contain the necessary drivers for the board. Greets, Fabian Today I tested it with the newest v4l-sources - also no multiple read accesses possible. Any suggestions? Hm, I tested budget and dvb-ttpci drivers from HG with kernel 2.6.22. Works without any problems here. 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] [PATCH] femon: added option for the count of printed lines
Hermann Gausterer wrote: hi i changed femon to accept an option for the number of printed lines; there is also a script attached which uses this to convenient print out the status of all dvb cards in a system! :-) i think, this script should be added to dvb-apps. patch is again http://www.linuxtv.org/downloads/linuxtv-dvb-1.1.1.tar.bz2 please reply in case of problems accepting the patch! linuxtv-dvb-1.1.1.tar.bz2 is _very_ old. Please use femon from the dvb-apps HG repository. | usage: femon [options] | -h: human readable output | -a number : use given adapter (default 0) | -f number : use given frontend (default 0) | -c number : samples to take (default 0 = infinite) There is already a -c option... 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] bus control
Manu Abraham wrote: On 7/25/07, Patrick Boettcher [EMAIL PROTECTED] wrote: On Mon, 23 Jul 2007, Oliver Endriss wrote: Manu Abraham wrote: Hi all, On one of the devices that i am working upon, it has a bus control entity. ie The device looks like this The device consists of 1) a BUS Interface Unit 2) on this bus Interface unit (BIU) there is one single physical I2C bus 3) a built in MASTER demodulator The I2C bus on the device is _not_ directly connected to any peripherals such as demods and or tuners. The bus goes to a control unit where the bus is split into 2 based on a control word sent to the Bus Control Unit (BCU) The split out bus goes out like this 1) goes to the MASTER tuner for the built in demodulator 2) goes to a SLAVE demodulator, which has just one switchable I2C output for the tuner ie , the configuration looks like 2, 2 way switches cascaded together, when the MASTER and SLAVE demodulators are cascaded. Looking at the device and thinking a lot, i don't see how the control can fit in as a part of the frontend at all, as the it has nothing to do with the frontend, but just the BIU. Some thought that i have, at present go like this * register independant virtual buses for each device, on device access, the relevant control word is appended to the BIU device register. Imho this is the preferred way. The master_xfer function of the virtual i2c bus could setup the BCU switch, then call master_xfer of the physical i2c bus. I second this idea. Exactly like this is how I did with the dib7000/3000 and the mt2060. It is the best and cleanest approach IMHO. Cool. Will proceed this way then without waiting much. As a nice side effect of this concept, you may use standard i2ctools (i2cdump, i2cset, i2cget) to access the devices connected to a virtual bus. 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 * firmware is copied from MASTER to SLAVE via VBus #0 to VBus #1 - 1 though the firmware download is a property of the demodulator, it would not be elegant from the demodulator hardware POV to download the firmware twice (the BIU host will be doing 2 transfers, one from the PC to the BIU Host and the BIU to the SLAVE) Does it take a long time to download the firmware? If not, I would go for the easiest way. (I guess the firmware has to be loaded after a coldstart only.) In this case the firmware has to be copied from demod #0 to demod #1 for effeciency reasons, though a dual download can be used. But AFAICS the firmware getting downloaded to the demod would be necessary in the SLAVE - SLAVE configuration as found on PCI/PCIe devices, since there is no BIU in that configuration. I think it might be better then, that the firmware download in the demodulators is conditionally done through a BIU config data structure in such a case (Thoughts ?) You might add a firmware_request callback to the configuration struct passed to the demod_attach routine (see tda1004x driver, for example). The card driver will set this entry before calling demod_attach. For a dual download, it might point to the same routine for each demod. For the download+copy approach, you might set the callback of the second demod to a special firmware copy routine. 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] bus control
Manu Abraham wrote: Hi all, On one of the devices that i am working upon, it has a bus control entity. ie The device looks like this The device consists of 1) a BUS Interface Unit 2) on this bus Interface unit (BIU) there is one single physical I2C bus 3) a built in MASTER demodulator The I2C bus on the device is _not_ directly connected to any peripherals such as demods and or tuners. The bus goes to a control unit where the bus is split into 2 based on a control word sent to the Bus Control Unit (BCU) The split out bus goes out like this 1) goes to the MASTER tuner for the built in demodulator 2) goes to a SLAVE demodulator, which has just one switchable I2C output for the tuner ie , the configuration looks like 2, 2 way switches cascaded together, when the MASTER and SLAVE demodulators are cascaded. Looking at the device and thinking a lot, i don't see how the control can fit in as a part of the frontend at all, as the it has nothing to do with the frontend, but just the BIU. Some thought that i have, at present go like this * register independant virtual buses for each device, on device access, the relevant control word is appended to the BIU device register. Imho this is the preferred way. The master_xfer function of the virtual i2c bus could setup the BCU switch, then call master_xfer of the physical i2c bus. This way any existing frontend driver might be used without modification. (Don't know if this is important.) 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
e9hack wrote:
Manfred Petz wrote:
actually, both patches help. no more timeouts, and the frontend drivers
get loaded correctly (tried each patch separately). tried with latest hg
2.6.22.
I don't understand why both patches do solve the timeout problem. The message
'timed out waiting for
end of xfer' means, that no i2c-interrupt was delivered. In this case, the
return value of
saa7146_i2c_writeout() is -EIO. The first patch has only an effect, if the
return value is
-EREMOTEIO. The second patch reduces the i2c bit-rate. Usually, it has
nothing to do with the
interrupts.
A lower i2c bit rate might have changed the timing.
Independently of this, I've found some strange things. The drivers for the
TT-C2300 and the Cinergy
DVB-C cards probe some i2c devices which don't exist. This results in an
address error (missing ACK
after the device address). I see three interrupts for this error. The first
sets I2C_BUSY and
I2C_APERR within I2C_STATUS. It does not wake-up the waiting thread and may
print the message
'unhandled irq: i2c'. The second interrupt is the normal error interrupt
which does wake-up the
thread. I2C_BUSSY, I2C_ERR and I2C_APERR are set. The third interrupt has set
the same three status
bits. It may print the message 'unexpected irq: i2c', because the thread was
already wake-up. If the
chip-set is only able to deliver the first interrupt, the error interrupt
will be never delivered
and the timeout occurs.
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.
CU
Oliver
--
VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/
diff -r 0f9dfb292f40 linux/drivers/media/common/saa7146_core.c
--- a/linux/drivers/media/common/saa7146_core.c Tue Jul 17 02:27:12 2007 +0200
+++ b/linux/drivers/media/common/saa7146_core.c Tue Jul 17 04:17:36 2007 +0200
@@ -252,18 +252,17 @@ static irqreturn_t interrupt_hw(int irq,
#endif
{
struct saa7146_dev *dev = dev_id;
- u32 isr = 0;
+ u32 isr;
+ u32 ack_isr;
/* read out the interrupt status register */
- isr = saa7146_read(dev, ISR);
+ ack_isr = isr = saa7146_read(dev, ISR);
/* is this our interrupt? */
if ( 0 == isr ) {
/* nope, some other device */
return IRQ_NONE;
}
-
- saa7146_write(dev, ISR, isr);
if( 0 != (dev-ext)) {
if( 0 != (dev-ext-irq_mask isr )) {
@@ -287,21 +286,16 @@ static irqreturn_t interrupt_hw(int irq,
isr = ~MASK_28;
}
if (0 != (isr (MASK_16|MASK_17))) {
- u32 status = saa7146_read(dev, I2C_STATUS);
- if( (0x3 == (status 0x3)) || (0 == (status 0x1)) ) {
- SAA7146_IER_DISABLE(dev, MASK_16|MASK_17);
- /* only wake up if we expect something */
- if( 0 != dev-i2c_op ) {
-u32 psr = (saa7146_read(dev, PSR) 16) 0x2;
-u32 ssr = (saa7146_read(dev, SSR) 17) 0x1f;
-DEB_I2C((irq: i2c, status: 0x%08x, psr:0x%02x, ssr:0x%02x).\n,status,psr,ssr));
-dev-i2c_op = 0;
-wake_up(dev-i2c_wq);
- } else {
-DEB_I2C((unexpected irq: i2c, status: 0x%08x, isr %#x\n,status, isr));
- }
+ SAA7146_IER_DISABLE(dev, MASK_16|MASK_17);
+ /* only wake up if we expect something */
+ if( 0 != dev-i2c_op ) {
+ dev-i2c_op = 0;
+ wake_up(dev-i2c_wq);
} else {
- DEB_I2C((unhandled irq: i2c, status: 0x%08x, isr %#x\n,status, isr));
+ u32 psr = saa7146_read(dev, PSR);
+ u32 ssr = saa7146_read(dev, SSR);
+ printk(KERN_WARNING saa7146: unexpected i2c irq: isr %08x psr %08x ssr %08x\n,
+ isr, psr, ssr);
}
isr = ~(MASK_16|MASK_17);
}
@@ -310,6 +304,7 @@ static irqreturn_t interrupt_hw(int irq,
ERR((disabling interrupt source(s)!\n));
SAA7146_IER_DISABLE(dev,isr);
}
+ saa7146_write(dev, ISR, ack_isr);
return IRQ_HANDLED;
}
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] KNC1 DVB-S CI?
P. van Gaans wrote: Things take a whole new turn. Apparently something went wrong with the cable to the CI daughterboard, after re-connecting it the card worked again in Windows. Now for Linux, with once again the normal v4l-dvb (not my modified version): [ 253.42] budget-av: cam inserted B [ 256.384000] dvb_ca adapter 0: DVB CAM detected and initialised successfully Yep, broken cables are a common cause of CI problems. I'll go test all my CAMs and update the wiki, thanks! Thanks for updating the docs! 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
Manfred Petz wrote:
On Sat, 2007-05-26 at 10:22 +0200, Soeren Sonnenburg wrote:
Dear list,
since post 2.6.19 I keep getting flooded with
saa7146_i2c_writeout: timed out waiting for end of xfer
hi,
i'm experiencing a similar problem. using 2.6.19.1 with latest hg dvb
driver (knc-1 dvb-s) everything works. though, from at least 2.6.19.7
on, with the same kernel config and same hardware (same dvb drivers), i
get those i2c timeouts and, when doing 'modprobe budget-av', not all
cards get deteced.
kernel: KNC1-5: Could not read MAC from KNC1 card
kernel: saa7146_i2c_writeout: timed out waiting for end of xfer
last message repeated 7 times
budget-av: A frontend driver was not found for device 1131/7146 subsystem
1894/0016
since i'm using the same dvb driver, that problem seems to be triggered
somewhere else.
Could you please try the attached patch (saa7146_i2c_retry.diff)?
If it does not help, please try the second patch
(budget-av_slowi2c.diff).
Any improvements?
Oliver
--
VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/
diff -r 39c2d2041e6e linux/drivers/media/common/saa7146_i2c.c
--- a/linux/drivers/media/common/saa7146_i2c.c Thu Jul 05 00:18:34 2007 +0200
+++ b/linux/drivers/media/common/saa7146_i2c.c Mon Jul 09 23:55:55 2007 +0200
@@ -329,9 +329,9 @@ int saa7146_i2c_transfer(struct saa7146_
completely for analog cards after an address error and trust
the saa7146 address error detection. */
if ( -EREMOTEIO == err ) {
- if( 0 != (SAA7146_USE_I2C_IRQ dev-ext-flags)) {
- goto out;
- }
+// if( 0 != (SAA7146_USE_I2C_IRQ dev-ext-flags)) {
+// goto out;
+// }
address_err++;
}
DEB_I2C((error while sending message(s). starting again.\n));
diff -r 39c2d2041e6e linux/drivers/media/dvb/ttpci/budget-av.c
--- a/linux/drivers/media/dvb/ttpci/budget-av.c Thu Jul 05 00:18:34 2007 +0200
+++ b/linux/drivers/media/dvb/ttpci/budget-av.c Tue Jul 10 00:07:09 2007 +0200
@@ -961,6 +961,7 @@ static void frontend_init(struct budget_
case SUBID_DVBS_CYNERGY1200N:
case SUBID_DVBS_EASYWATCH:
case SUBID_DVBS_EASYWATCH_2:
+ budget_av-budget.dev-i2c_bitrate = SAA7146_I2C_BUS_BIT_RATE_240;
fe = dvb_attach(stv0299_attach, philips_sd1878_config,
budget_av-budget.i2c_adap);
if (fe) {
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] KNC1 DVB-S CI?
P. van Gaans wrote: http://linuxtv.org/wiki/index.php/KNC1_TV-Station_DVB-S The wiki says The card has a CI connector but it most probably isn't supported by Linux.. I've got the card and indeed, it doesn't seem to work. There is a ca0 in /dev/dvb/adapter0 but in Kaffeine the encrypted channels are still black. But I wonder, with the DVB-C version of this card, the CI works without a hitch (and I should know, I own one). According to the wiki the DVB-T version also has a working CI. I somehow can't imagine the CI on the DVB-S version is so much different. Or am I wrong and is the CI not supported because it requires a lot of reverse engineering nobody feels like doing for this card? Maybe it is not supported because the driver developer did not have the hardware to play with... Is there anything I could try? If you have some programming skills you could try to debug budget-av.c and try to find out what's going wrong... 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] removal em28xx from linuxtv.org
timecop wrote: Hey guys, stop beating dead horses and finding scapegoats. Whatever excuses you're going to find post-fact isn't going to change the fact that HE now has working code with functionality better than the broken crap currently in linux-dvb, and YOU don't. Users (what little of them Linux still has) usually want stuff that WORKS, and they don't give two shits about HOW it works underneath. So when you stop accepting working solutions because of some bullshit political/etc reason, everyone loses. Exactly! People need working drivers! And they don't want that drivers, which are in in the kernel for a long time, will be broken in the next kernel release. That's the reason why I nack'd this patch bomb. No other reason! End of discussion. 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] TT S-1401 Error: A frontend driver was not found for device 1131/7146 subsystem 13c2/1018
Sebastian wrote: Hello, i recently bought a Technotrend S-1401 DVB-S card. Somehow this card wont work for me, because i dont get a frontend0 device. Other device nodes like demux0 or dvr0 are there, but frontend0 is missing. I am using Linux 2.6.20-16 (2.6.21 tested too) and the latest Mercurial DVB drivers. I get the following kernel messages with debug=1 in tda10086.c [ 34.452456] saa7146: register extension 'budget dvb'. [ 34.452508] ACPI: PCI Interrupt :02:08.0[A] - GSI 20 (level, low) - IRQ 22 [ 34.452535] saa7146: found saa7146 @ mem f8982000 (revision 1, irq 22) (0x13c2,0x1018). [ 34.452541] saa7146 (0): dma buffer size 192512 [ 34.452543] DVB: registering new adapter (TT-Budget-S-1401 PCI) [ 34.490315] adapter has MAC addr = 00:d0:5c:09:11:8e [ 34.552672] tda10086: tda10086_attach [ 34.552754] tda10086: tda10086_read_byte: error reg=0x1e, ret=-121 [ 34.552774] budget: A frontend driver was not found for device 1131/7146 subsystem 13c2/1018 function tda10086_attach expects tda10086_read_byte to return 0xe1, but it returns -121 instead. Since its very hard for me to understand this driver code, this is all i could find out till now. Does anybody have a clue what the problem is or how to fix it? Basically the driver should work. Are you sure that the card is ok, i.e. did you test the card with the windoes driver? 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] removal em28xx from linuxtv.org
CityK wrote: In any regard, its best to just ignore him. He's just trying to get a rise out of folks here. Probably you are right. And I will not participate in any flame wars. If someone is really interested to know what happened, he will hopefully read all relevant messages and draw his own conclusions. Then he will also find out who is posting technical arguments and who is insulting people all the time... CU Oliver P.S.: This was my last message in this thread. Really. ;-) -- 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] divide error with ST STV0297 DVB-C
Peter Maersk-Moller wrote: Hi When trying to tune with my TT Budget T1500,I get a divide error from the kernel. Tried 2.6.21.2 and 2.6.21.5. Is this a well known issue ? Not until now. Thanks for reporting. ;-) More info below. When I try to tune my TT Premium DVB-C (same front end ST STV0297 DVB-C) the same dvide error happens locking up the card. ... dvbtune -c 1 -f 562000 Using DVB card ST STV0297 DVB-C tuning DVB-C to 562000, srate=0 ^^^ Please test whether it works when you use a sane symbol rate. 0 does not make sense. ... Jun 14 20:36:09 dvb01 kernel: EIP is at stv0297_set_sweeprate+0xa/0x5f [stv0297] ... Apparently, specifying symbol rate 0 causes a divide-by-zero error in stv0297_set_sweeprate(). Anyway, the driver should not crash. I'll apply a fix asap. 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] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
Trent Piepho wrote: I'm still unclear on exactly what the stv0297 requires. The datasheet says one can't use a repeated start, but must have a stop between a read and a write. That's simple enough, but has anyone actually verified that the datasheet is really correct? I know many datasheets provide some _examples_ of i2c transactions, but it's by no means an exahstive list. Just because something isn't listed doesn't mean it won't work too. Ack. Does the stv0297 require that no other i2c traffic, to a different device, appear between the write and the read? Something like: S stv_addr_W A reg_addr A P S tuner_addr_W A tuner_data1 A tuner_data2 A P S stv_addr_R A reg_data NA P Will the i2c message to the tuner between the two parts of the stv register reading sequence be a problem? AFAICS no I2C device may assume that two consecutive I2C accesses go to its own device address, or the device is totally broken. 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] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
e9hack wrote: Trent Piepho wrote: Does the stv0297 require that no other i2c traffic, to a different device, appear between the write and the read? Something like: S stv_addr_W A reg_addr A P S tuner_addr_W A tuner_data1 A tuner_data2 A P S stv_addr_R A reg_data NA P Will the i2c message to the tuner between the two parts of the stv register reading sequence be a problem? The tuner may be a problem, because the stv0297 is the gate for the tuner i2c-bus. Correct. Since the I2C gate closes after the following stop condition, we have a problem, if another I2C transfer happens between gate open and PLL access: (1) S stv_addr_W A ...open_gate... P (2) S eeprom_addr_W A reg_addr A Sr eeprom_addr_R A reg_data NA P (3) S pll_addr_W A ...pll_data... P will not work because the I2C gate closes after (2)! Reading from eeprom does work: S stv_addr_W A reg_addr A P S eeprom_addr_W A reg_addr A Sr eeprom_addr_R A reg_data NA P S stv_addr_R A reg_data NA P Could you please test whether this works: S stv_addr_W A reg_addr A Sr stv_addr_R A reg_data NA P 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] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
e9hack wrote: Oliver Endriss wrote: Could you please test whether this works: S stv_addr_W A reg_addr A Sr stv_addr_R A reg_data NA P It doesn't work. Hm, I wonder how stv0297_readregsI() in stv0297_cs2.c could ever work. Any idea? The following does work, if the Stop-Start isn't located in the same upload command of the saa7146: S stv_addr_W A reg_addr A P S stv_addr_R A reg_data NA P Yes, this is basically what stv0297_readreg() in stv0297.c does. 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] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
Oliver Endriss wrote: e9hack wrote: Oliver Endriss wrote: Could you please test whether this works: S stv_addr_W A reg_addr A Sr stv_addr_R A reg_data NA P It doesn't work. Hm, I wonder how stv0297_readregsI() in stv0297_cs2.c could ever work. Any idea? Answering myself: It's used by the flexcop driver only, and flexcop_i2c_read4() contains a hack for this case... 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] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
Manu Abraham wrote: On 6/2/07, Johannes Stezenbach [EMAIL PROTECTED] wrote: On Fri, Jun 01, 2007, Oliver Endriss wrote: e9hack wrote: Manu Abraham wrote: e9hack wrote: Manu Abraham wrote: Trent Piepho wrote: What the stv0297 wants is: S Addr Wr [A] Comm [A] P S Addr Rd [A] [Data] NA P The STV0297 is just a normal demod like the others, nothing special about it (according to ST). Well of course i2cdump can be wrong. The stv0297 cannot handle a repeated start condition and it needs a little delay between the stop and the next start condition. A stop and a start condition cannot be on the same upload command of a saa7146 (on a TT 2300C). Any idea what the SAA7146 - STV0297 windows driver does ? Good point. I can monitor any access to the saa7146 registers of the TT 2300C on Windows. I will check this issue. In the past, I was more interested in the high level part of the i2c-communication. Any news about this? Imho Trent's patch to add I2C_M_STOP makes sense. According to the stv0299 datasheet, the stv0299 requires this STOP condition, too. This chip seems to be more tolerant though. The current driver does not send STOP before READ, and it works. I re-read the i2c spec (conveniently available from http://i2c-bus.org/ ), and although it doesn't use very clear words I think it says that any device _must_ support repeated start conditions (e.g. section 9 FORMATS WITH 7-BIT ADDRESSES). I just miss a few points in there.. from the URL that you pasted in. The I2C protocol defines a so-called repeated start condition. After having sent the address byte (address and read/write bit) the master may send any number of bytes followed by a stop condition. AFAICS repeated start conditions must be supported by all I2C devices. Furthermore, section 9 note 4 specifies that a device has to accept a start condition anytime, but that's more related to error recovery IMHO. The STV0297 requires a STOP bit in between as stated. That's what the datasheet says. Same for stv0299. There's also some more explanation: http://i2c-bus.org/RepeatedStartCondition/ Now, it could well be that the stv0297 i2c interface is broken (broken because it cannot safely be used on a bus with multiple masters), but it may also be quite possible that the stv0297 datasheet is just inaccurate. Will any comments from STM would help ? If so, will request STM to answer some questions that we have, if any explicit ones you have, i can add them alongwith. Just that i got a bit confused now. If you have a contact at STM, that would be great. According to the datasheet, a read operation must look like this: (a) S waddr A reg A P S raddr A data A P According to the I2C standard, a device must support this, too: (b) S waddr A reg A Sr raddr A data A P S = start, P = stop, Sr = repeated start, A = acknowledge, waddr = address[write], raddr = address[read] I hope that the stv0297/stv0299 datasheets are incorrect/incomplete, and a type (b) transaction is supported, too. If not, the device cannot be used in a multi-master environment. (Note that a repeated start condition is used to 'lock' the I2C bus for the master which is currently accessing the device.) In this case we have have to add something like the M_STOP workaround to I2C core. Otherwise accessing the stv0297 would not be thread-safe... IMHO both possibilities are just as likely, however I trust adq has actually tested that repeat start doesn't work. http://linuxtv.org/hg/v4l-dvb/rev/c204a1d063aa Then I2C_M_STOP still makes sense, but the patch should document that it's used only a workaround for broken hardware. 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] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
e9hack wrote: Manu Abraham wrote: e9hack wrote: Manu Abraham wrote: Trent Piepho wrote: What the stv0297 wants is: S Addr Wr [A] Comm [A] P S Addr Rd [A] [Data] NA P The STV0297 is just a normal demod like the others, nothing special about it (according to ST). Well of course i2cdump can be wrong. The stv0297 cannot handle a repeated start condition and it needs a little delay between the stop and the next start condition. A stop and a start condition cannot be on the same upload command of a saa7146 (on a TT 2300C). Any idea what the SAA7146 - STV0297 windows driver does ? Good point. I can monitor any access to the saa7146 registers of the TT 2300C on Windows. I will check this issue. In the past, I was more interested in the high level part of the i2c-communication. Any news about this? Imho Trent's patch to add I2C_M_STOP makes sense. According to the stv0299 datasheet, the stv0299 requires this STOP condition, too. This chip seems to be more tolerant though. The current driver does not send STOP before READ, and it works. CU 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
Re: [linux-dvb] patch budget-av: Remove polarity switching of the clock for the DVB-C cards causes corrupt stream
Matthias Dahl wrote: Hi Hartmut. it seems that newer windows drivers for the KNC ONE/Satelco EasyWatch/Terratec Cinergy do not longer use the VPE interrupt to transfer data. They use the the PORT A/B interrupt. Can you please try the attached patch (with and without the CI/CAM)? The patch uses also the PORT A/B interrupt. I've tested it with my Cinergy 1200C (without a CI). Great! The patch fixes the problem with the corrupt stream. I have been hitting at it for an hour now and haven't been able to cause any vpeirq msgs nor corrupted streams. Thanks a lot! :-) Hope this gets into the official tree... Strange - I wonder why it makes a difference whether you use the A/B or the VPE interrupt? Anyway, this mode of operation should be used only for large buffer mode, i.e. when odd/even buffers are in use. For single buffer mode we should leave the code as is. CU 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
