Re: [PATCH] drivers/media/dvb/dvb-core/dvb_net.c: use %pM to show MAC address
From: H Hartley Sweeten hartl...@visionengravers.com Date: Tue, 5 Jan 2010 09:45:21 -0700 Use the %pM kernel extension to display the MAC address and mask. The only difference in the output is that the output is shown in the usual colon-separated hex notation. Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com Applied. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
New init DVB-T file for fr-Saint-Jorioz-1 (Saint-Germain / Talloire)]
Hello, Here is my complete init dvb file for the new location fr-Saint-Jorioz-1 (Saint-Germain / Talloire). Best regards. Benoît France 2:49000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:120:130:257 France 5:49000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:320:330:260 ARTE:49000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:520:530:261 LCP:49000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:620:630:262 France 3 ALPES:49000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:220:230:311 [01ff]:49000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:0:0:511 Direct 8:51400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:160:80:513 BFM TV:51400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:162:88:515 iTELE:51400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:163:92:516 Virgin 17:51400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:164:96:517 Gulli:51400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:165:100:518 France 4:51400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:166:104:519 [02ff]:51400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:0:0:767 CANAL+:53800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:160:0:769 CANAL+ CINEMA:53800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:161:0:770 CANAL+ SPORT:53800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:162:0:771 PLANETE:53800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:163:92:772 TPS STAR:53800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:165:100:774 [03f0]:53800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:0:0:1008 [03f1]:53800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:0:0:1009 [03f2]:53800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:0:0:1010 [03f3]:53800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:0:0:1011 M6:71400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:120:130:1025 W9:71400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:220:230:1026 NT1:71400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:320:330:1027 PARIS PREMIERE:71400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:420:430:1028 ARTE HD:71400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:720:730:1031 [04ff]:71400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:0:0:1279 temp:71400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:0:0:1030 TF1:73800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:120:130:1537 NRJ12:73800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:220:230:1538 LCI:73800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:320:330:1539 Eurosport :73800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:420:430:1540
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Hi, The 6MHz patch is for Taiwan only. It should not change anything for 7MHz and 8MHz. Terry 2010/1/7 Robert Lowery rglow...@exemail.com.au: On Wed, 2010-01-06 at 14:20 +1100, Robert Lowery wrote: On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote: On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote: Mauro, I've split the revert2.diff that I sent you previously to fix the tuning regression on my DViCO Dual Digital 4 (rev 1) into three separate patches that will hopefully allow you to review more easily. The first two patches revert their respective changesets and nothing else, fixing the issue for me. 12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T 11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @ 6MHz The third patch does what I believe is the obvious equivalent fix to e6a8672631a0 but without the cleanup that breaks tuning on my card. Please review and merge Signed-off-by: Robert Lowery rglow...@exemail.com.au Mauro, I'm yet to receive a response from you on this clear regression introduced in the 2.6.31 kernel. You attention would be appreciated Thanks -Rob Robert, The changes in question (mostly authored by me) are based on documentation on what offsets are to be used with the firmware for various DVB bandwidths and demodulators. The change was tested by Terry on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028) and some other cards I can't remember, using a DVB-T pattern generator for 7 and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz. (Devin, Maybe you can double check on the offsets in tuner-xc2028.c with any documentation you have available to you?) I haven't been following this thread really at all as the board in the subject line was unfamiliar to me, so sorry for any late response or dumb questions by me. May I ask: 1. what are the exact problem frequencies? 2. what is the data source from which you are getting the frequency information? 3. what does tuner-xc2028 debug logging show as the firmware loaded when tune to one of the the problem frequencies? Robert, I just found that ACMA has a very nice compilation licensed DTV transmitters in Australia and their frequencies. Have a look at the Excel spreadsheet linked on this page: http://acma.gov.au/WEB/STANDARD/pc=PC_9150 The DTV tab has a list of the Area, callsign, and DTV center freq. The Glossary tab mentions that DTV broadcasters can have an offset of +/- 125 kHz from the DTV center freq. If you could verify that the frequencies you are using for the problem stations match the list, that would help eliminate commanded tuning frequency as source of the problem. Andy, I don't think this issue is frequency, it is the removal of the 500kHz offset. OK. I forgot there were two offsets at play here: one for the RF frequency and one for the SCODE/Intermediate Frequency. Right, the S-CODE offsets are somewhat of a mystery to me as I don't exactly know the mathematical basis behind them. The 500 kHz came from the best interpretation Maruo and I could make at the time, but it could very well be the wrong thing. (I was guessing it came from a relation something like this: 8 MHz - 7 MHz / 2 = 500 kHz) If it is the wrong thing, and it looks like it could be, we can back it out. As my colleauge, who used to work at CERN, says Experiment trumps theory ... *every* time. Terry had positive results, you and Vincent have negative results. So I'd like to see what Devin finds, if he can test with a DVB-T generator. Andy, Resend of my proposed patches attached. My hypothesis is that 02_revert_e6a8672631a0.diff was really meant to just change the ATSC test to DTV6 but at the same time a cleanup that was done inadvertently removed the 500kHz offset subtraction for DTV7 introducing the defect. 01_revert_966ce12c444d.diff partially fixed this regression for Terry, but not for me or Vincent. I'm having trouble convincing Mauro of this though :), so I would appreciate it if Terry could test my patch set and confirm it is ok for him. So in short, my 01 and 02 patches attached revert the changes that break tuning for me and 03 re-implements the DTV6 fix, but without the cleanup which breaks me. Please review and comment -Rob The channel with the biggest problem (most stuttering) is Channel 8 in Melbourne, which looks correct at 191.625 MHz on the above site. OK. Vincent must have been the one with all the Sydney stations. DTV Channel GTV8 (Fc = 191.625 MHz at 50 kW) for Melbourne is interesting; it comes from the same towers as the adjacent analog channels HSV7 (Fr = 182.25 MHz @ 200 kW) and GTV9 (Fr = 196.25 MHz @ 200 kW). I guess if anything is off center when setting up the XC3028, the analog stations may show up as strong noise - a situation that would
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Hi, And the 6MHz patch you mentioned is a wrong patch. http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 + if (priv-cur_fw.type DTV6) + offset = 175; + if (priv-cur_fw.type DTV7) + offset = 225; + else/* DTV8 or DTV78 */ + offset = 275; and latest patch should be: + if (priv-cur_fw.type DTV6) + offset = 175; + else if (priv-cur_fw.type DTV7) + offset = 225; + else/* DTV8 or DTV78 */ + offset = 275; Terry 2010/1/7 Terry Wu terrywu2...@gmail.com: Hi, The 6MHz patch is for Taiwan only. It should not change anything for 7MHz and 8MHz. Terry 2010/1/7 Robert Lowery rglow...@exemail.com.au: On Wed, 2010-01-06 at 14:20 +1100, Robert Lowery wrote: On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote: On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote: Mauro, I've split the revert2.diff that I sent you previously to fix the tuning regression on my DViCO Dual Digital 4 (rev 1) into three separate patches that will hopefully allow you to review more easily. The first two patches revert their respective changesets and nothing else, fixing the issue for me. 12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T 11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @ 6MHz The third patch does what I believe is the obvious equivalent fix to e6a8672631a0 but without the cleanup that breaks tuning on my card. Please review and merge Signed-off-by: Robert Lowery rglow...@exemail.com.au Mauro, I'm yet to receive a response from you on this clear regression introduced in the 2.6.31 kernel. You attention would be appreciated Thanks -Rob Robert, The changes in question (mostly authored by me) are based on documentation on what offsets are to be used with the firmware for various DVB bandwidths and demodulators. The change was tested by Terry on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028) and some other cards I can't remember, using a DVB-T pattern generator for 7 and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz. (Devin, Maybe you can double check on the offsets in tuner-xc2028.c with any documentation you have available to you?) I haven't been following this thread really at all as the board in the subject line was unfamiliar to me, so sorry for any late response or dumb questions by me. May I ask: 1. what are the exact problem frequencies? 2. what is the data source from which you are getting the frequency information? 3. what does tuner-xc2028 debug logging show as the firmware loaded when tune to one of the the problem frequencies? Robert, I just found that ACMA has a very nice compilation licensed DTV transmitters in Australia and their frequencies. Have a look at the Excel spreadsheet linked on this page: http://acma.gov.au/WEB/STANDARD/pc=PC_9150 The DTV tab has a list of the Area, callsign, and DTV center freq. The Glossary tab mentions that DTV broadcasters can have an offset of +/- 125 kHz from the DTV center freq. If you could verify that the frequencies you are using for the problem stations match the list, that would help eliminate commanded tuning frequency as source of the problem. Andy, I don't think this issue is frequency, it is the removal of the 500kHz offset. OK. I forgot there were two offsets at play here: one for the RF frequency and one for the SCODE/Intermediate Frequency. Right, the S-CODE offsets are somewhat of a mystery to me as I don't exactly know the mathematical basis behind them. The 500 kHz came from the best interpretation Maruo and I could make at the time, but it could very well be the wrong thing. (I was guessing it came from a relation something like this: 8 MHz - 7 MHz / 2 = 500 kHz) If it is the wrong thing, and it looks like it could be, we can back it out. As my colleauge, who used to work at CERN, says Experiment trumps theory ... *every* time. Terry had positive results, you and Vincent have negative results. So I'd like to see what Devin finds, if he can test with a DVB-T generator. Andy, Resend of my proposed patches attached. My hypothesis is that 02_revert_e6a8672631a0.diff was really meant to just change the ATSC test to DTV6 but at the same time a cleanup that was done inadvertently removed the 500kHz offset subtraction for DTV7 introducing the defect. 01_revert_966ce12c444d.diff partially fixed this regression for Terry, but not for me or Vincent. I'm having trouble convincing Mauro of this though :), so I would appreciate it if Terry could test my patch set and confirm it is ok for him. So in short, my 01 and 02 patches attached revert
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Hi, The following codes in the 6MHz patch are not for 6MHz. Please read the mchehab's comments. 1.28/* 1.29 - * We must adjust the offset by 500kHz in two cases in order 1.30 - * to correctly center the IF output: 1.31 - * 1) When the ZARLINK456 or DIBCOM52 tables were explicitly 1.32 - *selected and a 7MHz channel is tuned; 1.33 - * 2) When tuning a VHF channel with DTV78 firmware. 1.34 + * We must adjust the offset by 500kHz when 1.35 + * tuning a 7MHz VHF channel with DTV78 firmware 1.36 + * (used in Australia) 1.37 */ 1.38 - if (((priv-cur_fw.type DTV7) 1.39 - (priv-cur_fw.scode_table (ZARLINK456 | DIBCOM52))) || 1.40 - ((priv-cur_fw.type DTV78) freq 47000)) 1.41 + if ((priv-cur_fw.type DTV78) freq 47000) 1.42offset -= 50; BTW, the DTV7 firmware or DTV78 firmware is using if you are tuning a VHF channel (frequency 470MHz). And the above mchehab's new codes will not do offset -= 50; if DTV7 firmware is using. Terry 2010/1/7 Terry Wu terrywu2...@gmail.com: Hi, And the 6MHz patch you mentioned is a wrong patch. http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 + if (priv-cur_fw.type DTV6) + offset = 175; + if (priv-cur_fw.type DTV7) + offset = 225; + else /* DTV8 or DTV78 */ + offset = 275; and latest patch should be: + if (priv-cur_fw.type DTV6) + offset = 175; + else if (priv-cur_fw.type DTV7) + offset = 225; + else /* DTV8 or DTV78 */ + offset = 275; Terry 2010/1/7 Terry Wu terrywu2...@gmail.com: Hi, The 6MHz patch is for Taiwan only. It should not change anything for 7MHz and 8MHz. Terry 2010/1/7 Robert Lowery rglow...@exemail.com.au: On Wed, 2010-01-06 at 14:20 +1100, Robert Lowery wrote: On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote: On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote: Mauro, I've split the revert2.diff that I sent you previously to fix the tuning regression on my DViCO Dual Digital 4 (rev 1) into three separate patches that will hopefully allow you to review more easily. The first two patches revert their respective changesets and nothing else, fixing the issue for me. 12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T 11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @ 6MHz The third patch does what I believe is the obvious equivalent fix to e6a8672631a0 but without the cleanup that breaks tuning on my card. Please review and merge Signed-off-by: Robert Lowery rglow...@exemail.com.au Mauro, I'm yet to receive a response from you on this clear regression introduced in the 2.6.31 kernel. You attention would be appreciated Thanks -Rob Robert, The changes in question (mostly authored by me) are based on documentation on what offsets are to be used with the firmware for various DVB bandwidths and demodulators. The change was tested by Terry on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028) and some other cards I can't remember, using a DVB-T pattern generator for 7 and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz. (Devin, Maybe you can double check on the offsets in tuner-xc2028.c with any documentation you have available to you?) I haven't been following this thread really at all as the board in the subject line was unfamiliar to me, so sorry for any late response or dumb questions by me. May I ask: 1. what are the exact problem frequencies? 2. what is the data source from which you are getting the frequency information? 3. what does tuner-xc2028 debug logging show as the firmware loaded when tune to one of the the problem frequencies? Robert, I just found that ACMA has a very nice compilation licensed DTV transmitters in Australia and their frequencies. Have a look at the Excel spreadsheet linked on this page: http://acma.gov.au/WEB/STANDARD/pc=PC_9150 The DTV tab has a list of the Area, callsign, and DTV center freq. The Glossary tab mentions that DTV broadcasters can have an offset of +/- 125 kHz from the DTV center freq. If you could verify that the frequencies you are using for the problem stations match the list, that would help eliminate commanded tuning frequency as source of the problem. Andy, I don't think this issue is frequency, it is the removal of the 500kHz offset. OK. I forgot there were two offsets at play here:
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Hi, You can check the dmesg output to verify which XCEIVE firmware/SCODE is using. For examples, (1). DVB-T 7MHz bandwidth, frequency=177.5MHz and BASE F8MHZ/DTV7 firmware is using, SCODE SCODE DTV7 ZARLINK456/HAS_IF_5260 [ 266.008596] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3), id . [ 267.098011] xc2028 0-0061: Loading firmware for type=D2633 DTV7 (90), id . [ 267.48] xc2028 0-0061: Loading SCODE for type=DTV7 ZARLINK456 SCODE HAS_IF_5260 (6280), id . (2). DVB-T 7MHz bandwidth, frequency=177.5MHz and BASE F8MHZ/DTV78 firmware is using, SCODE DTV78 ZARLINK456/SCODE HAS_IF_4760 [ 1089.192377] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3), id . [ 1090.265461] xc2028 0-0061: Loading firmware for type=D2633 DTV78 (110), id . [ 1090.278523] xc2028 0-0061: Loading SCODE for type=DTV78 ZARLINK456 SCODE HAS_IF_4760 (62000100), id . Terry 2010/1/7 Terry Wu terrywu2...@gmail.com: Hi, The following codes in the 6MHz patch are not for 6MHz. Please read the mchehab's comments. 1.28 /* 1.29 - * We must adjust the offset by 500kHz in two cases in order 1.30 - * to correctly center the IF output: 1.31 - * 1) When the ZARLINK456 or DIBCOM52 tables were explicitly 1.32 - * selected and a 7MHz channel is tuned; 1.33 - * 2) When tuning a VHF channel with DTV78 firmware. 1.34 + * We must adjust the offset by 500kHz when 1.35 + * tuning a 7MHz VHF channel with DTV78 firmware 1.36 + * (used in Australia) 1.37 */ 1.38 - if (((priv-cur_fw.type DTV7) 1.39 - (priv-cur_fw.scode_table (ZARLINK456 | DIBCOM52))) || 1.40 - ((priv-cur_fw.type DTV78) freq 47000)) 1.41 + if ((priv-cur_fw.type DTV78) freq 47000) 1.42 offset -= 50; BTW, the DTV7 firmware or DTV78 firmware is using if you are tuning a VHF channel (frequency 470MHz). And the above mchehab's new codes will not do offset -= 50; if DTV7 firmware is using. Terry 2010/1/7 Terry Wu terrywu2...@gmail.com: Hi, And the 6MHz patch you mentioned is a wrong patch. http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 + if (priv-cur_fw.type DTV6) + offset = 175; + if (priv-cur_fw.type DTV7) + offset = 225; + else /* DTV8 or DTV78 */ + offset = 275; and latest patch should be: + if (priv-cur_fw.type DTV6) + offset = 175; + else if (priv-cur_fw.type DTV7) + offset = 225; + else /* DTV8 or DTV78 */ + offset = 275; Terry 2010/1/7 Terry Wu terrywu2...@gmail.com: Hi, The 6MHz patch is for Taiwan only. It should not change anything for 7MHz and 8MHz. Terry 2010/1/7 Robert Lowery rglow...@exemail.com.au: On Wed, 2010-01-06 at 14:20 +1100, Robert Lowery wrote: On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote: On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote: Mauro, I've split the revert2.diff that I sent you previously to fix the tuning regression on my DViCO Dual Digital 4 (rev 1) into three separate patches that will hopefully allow you to review more easily. The first two patches revert their respective changesets and nothing else, fixing the issue for me. 12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T 11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @ 6MHz The third patch does what I believe is the obvious equivalent fix to e6a8672631a0 but without the cleanup that breaks tuning on my card. Please review and merge Signed-off-by: Robert Lowery rglow...@exemail.com.au Mauro, I'm yet to receive a response from you on this clear regression introduced in the 2.6.31 kernel. You attention would be appreciated Thanks -Rob Robert, The changes in question (mostly authored by me) are based on documentation on what offsets are to be used with the firmware for various DVB bandwidths and demodulators. The change was tested by Terry on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028) and some other cards I can't remember, using a DVB-T pattern generator for 7 and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz. (Devin, Maybe you can double check on the offsets in tuner-xc2028.c with any documentation you have available to you?) I haven't been following this thread really at all as the board in the subject line was unfamiliar to me, so sorry for any late
RE: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
Kevin, OK, I'm not extremely familar with the whole video architecture here, but are all of these drivers expected to be doing clk_get() and clk_enable()? [MK]Many IPs on DaVinci VPFE would require vpss master clock. So it is better to do the way I have done in my patch. So it is expected that clk_get, clk_enable etc are called from other drivers as well. I thought the point of moving the clocks into the CCDC driver was so that the clock management was done in a single, shared space. [MK] No. The CCDC IP is used across DaVinci and OMAP SOCs. The clock is named differently on OMAP, but the IP requires two clocks. So we named them as master and slave as a generic name. OMAP, patform code will be mapping master and slave clocks to their respective clocks. We had discussed this in the email chain. Murali Kevin Your earlier suggestion was to use as follows :- - CLK(NULL, vpss_master, vpss_master_clk), - CLK(NULL, vpss_slave, vpss_slave_clk), + CLK(vpfe-capture, master, vpss_master_clk), + CLK(vpfe-capture, slave, vpss_slave_clk), I am not sure if the following will work so that it can be used across multiple drivers. + CLK(NULL, master, vpss_master_clk), + CLK(NULL, slave, vpss_slave_clk), If yes, I can re-do this patch. Please confirm. No, this will not work. You need a dev_id field so that matching is done using the struct device. My original suggestion was when you had the VPFE driver doing the clk_get(). Now that it's in CCDC, maybe it should look like this. -CLK(NULL, vpss_master, vpss_master_clk), -CLK(NULL, vpss_slave, vpss_slave_clk), +CLK(ccdc, master, vpss_master_clk), +CLK(ccdc, slave, vpss_slave_clk), Kevin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
Karicheri, Muralidharan m-kariche...@ti.com writes: Kevin, OK, I'm not extremely familar with the whole video architecture here, but are all of these drivers expected to be doing clk_get() and clk_enable()? [MK]Many IPs on DaVinci VPFE would require vpss master clock. So it is better to do the way I have done in my patch. So it is expected that clk_get, clk_enable etc are called from other drivers as well. OK, then you are expecting to add clkdev nodes for the other devices as well. That's ok. However, you still haven't answered my original question. AFAICT, there are no users of the clkdev nodes vpss_master and vpss_slave. Why not remove those and replace them with your new nodes instead of leaving them and adding new ones? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Jan 7 19:00:02 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13879:b6b82258cf5e gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.33-rc2-armv5: ERRORS linux-2.6.32-armv5-davinci: OK linux-2.6.33-rc2-armv5-davinci: ERRORS linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.33-rc2-armv5-ixp: ERRORS linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.33-rc2-armv5-omap2: ERRORS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: WARNINGS linux-2.6.32-i686: WARNINGS linux-2.6.33-rc2-i686: ERRORS linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.33-rc2-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.33-rc2-mips: ERRORS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: WARNINGS linux-2.6.33-rc2-powerpc64: ERRORS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: WARNINGS linux-2.6.32-x86_64: WARNINGS linux-2.6.33-rc2-x86_64: ERRORS spec: OK sparse (linux-2.6.32): ERRORS sparse (linux-2.6.33-rc2): ERRORS linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DTV2000 H Plus issues
On Thu, Jan 7, 2010 at 2:49 PM, istva...@mailbox.hu istva...@mailbox.hu wrote: On 01/05/2010 02:25 AM, Raena Lea-Shannon wrote: Thanks. Will try again later. By the way, for those who would like to test it, here is a patch based on Devin Heitmueller's XC4000 driver and Mirek Slugen's older patch, that adds support for this card: http://www.sharemation.com/IstvanV/v4l/dtv2000h+.patch It can be applied to this version of the v4l-dvb code: http://linuxtv.org/hg/v4l-dvb/archive/75c97b2d1a2a.tar.bz2 This is experimental code, so use it at your own risk. The analogue parts (TV and FM radio) basically work, although there are some minor issues to be fixed. Digital TV is not tested yet, but is theoretically implemented; reports on whether it actually works are welcome. The XC4000 driver also requires a firmware file: http://www.sharemation.com/IstvanV/v4l/dvb-fe-xc4000-1.4.1.fw -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Istan_v, Could you please do me a favor and rename your firmware file, both in the patch and the file you are redistributing (perhaps as dvb-fe-xc4000-1.4.1-istanv.fw)? I worry that by redistributing a file with the exact same name as the official release, people are going to get confused and it will make it harder for me to debug problems given my assumptions about what firmware image they are using is incorrect. Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DTV2000 H Plus issues
On 01/07/2010 09:00 PM, Devin Heitmueller wrote: Could you please do me a favor and rename your firmware file, both in the patch and the file you are redistributing (perhaps as dvb-fe-xc4000-1.4.1-istanv.fw)? I worry that by redistributing a file with the exact same name as the official release, people are going to get confused and it will make it harder for me to debug problems given my assumptions about what firmware image they are using is incorrect. OK, I have renamed the firmware file. The download links are now: http://www.sharemation.com/IstvanV/v4l/dtv2000h+.patch http://www.sharemation.com/IstvanV/v4l/xc4000-dtv2000hp-1.4.1.fw -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
Kevin, Can I remove it through a separate patch? This patch is already merged in Hans tree. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, January 07, 2010 2:44 PM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open- sou...@linux.davincidsp.com Subject: Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver Karicheri, Muralidharan m-kariche...@ti.com writes: Kevin, OK, I'm not extremely familar with the whole video architecture here, but are all of these drivers expected to be doing clk_get() and clk_enable()? [MK]Many IPs on DaVinci VPFE would require vpss master clock. So it is better to do the way I have done in my patch. So it is expected that clk_get, clk_enable etc are called from other drivers as well. OK, then you are expecting to add clkdev nodes for the other devices as well. That's ok. However, you still haven't answered my original question. AFAICT, there are no users of the clkdev nodes vpss_master and vpss_slave. Why not remove those and replace them with your new nodes instead of leaving them and adding new ones? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
Karicheri, Muralidharan m-kariche...@ti.com writes: Can I remove it through a separate patch? This patch is already merged in Hans tree. Hmm, arch patches should not be merged yet as I have not ack'd them. Kevin -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, January 07, 2010 2:44 PM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open- sou...@linux.davincidsp.com Subject: Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver Karicheri, Muralidharan m-kariche...@ti.com writes: Kevin, OK, I'm not extremely familar with the whole video architecture here, but are all of these drivers expected to be doing clk_get() and clk_enable()? [MK]Many IPs on DaVinci VPFE would require vpss master clock. So it is better to do the way I have done in my patch. So it is expected that clk_get, clk_enable etc are called from other drivers as well. OK, then you are expecting to add clkdev nodes for the other devices as well. That's ok. However, you still haven't answered my original question. AFAICT, there are no users of the clkdev nodes vpss_master and vpss_slave. Why not remove those and replace them with your new nodes instead of leaving them and adding new ones? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compro VideoMate U80 DVB-T USB 2.0 High Definition Digital TV Stick
Can you give us the USB ID (type on the command line: lsusb, and report the output) The U90 has a RTL2831 in it. More info on the driver on: http://www.linuxtv.org/wiki/index.php/Rtl2831_devices drappa wrote: Hi All http://www.comprousa.com/en/product/u80/u80.html I'd be grateful if anyone can tell me if this device is supported yet, and if so, any pointers to getting it working. Thanks Drappa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
building v4l-dvb - compilation error
Hi, I have installed mercurial and cloned the v4l-dvb tree. I tried doing a build as per instructions and I get the following error. Since I am in the process of validating my build environment, I am not sure if the following is a genuine build error or due to my environment... Other questions I have are:- 1) I am just doing make. So does this build all v4l2 drivers? 2) Which target this build for? 3) What output this build create? CC [M] /local/mkaricheri/mercury/v4l-dvb/v4l/tuner-simple.o In file included from /local/mkaricheri/mercury/v4l-dvb/v4l/tuner-simple.c:9: /local/mkaricheri/mercury/v4l-dvb/v4l/compat.h:463: warning: struct snd_card d eclared inside parameter list /local/mkaricheri/mercury/v4l-dvb/v4l/compat.h:463: warning: its scope is only t his definition or declaration, which is probably not what you want /local/mkaricheri/mercury/v4l-dvb/v4l/tuner-simple.c:32: error: invalid lvalue i n unary `' /local/mkaricheri/mercury/v4l-dvb/v4l/tuner-simple.c:32: error: initializer elem ent is not constant /local/mkaricheri/mercury/v4l-dvb/v4l/tuner-simple.c:32: error: (near initializa tion for `__param_arr_atv_input.num') /local/mkaricheri/mercury/v4l-dvb/v4l/tuner-simple.c:33: error: invalid lvalue i n unary `' /local/mkaricheri/mercury/v4l-dvb/v4l/tuner-simple.c:33: error: initializer elem ent is not constant /local/mkaricheri/mercury/v4l-dvb/v4l/tuner-simple.c:33: error: (near initializa tion for `__param_arr_dtv_input.num') make[3]: *** [/local/mkaricheri/mercury/v4l-dvb/v4l/tuner-simple.o] Error 1 make[2]: *** [_module_/local/mkaricheri/mercury/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/kernels/2.6.9-55.0.12.EL-smp-i686' make[1]: *** [default] Error 2 Murali Karicheri -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
Arch patches are not usually merged in Hans tree. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, January 07, 2010 4:50 PM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open- sou...@linux.davincidsp.com Subject: Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver Karicheri, Muralidharan m-kariche...@ti.com writes: Can I remove it through a separate patch? This patch is already merged in Hans tree. Hmm, arch patches should not be merged yet as I have not ack'd them. Kevin -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, January 07, 2010 2:44 PM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open- sou...@linux.davincidsp.com Subject: Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver Karicheri, Muralidharan m-kariche...@ti.com writes: Kevin, OK, I'm not extremely familar with the whole video architecture here, but are all of these drivers expected to be doing clk_get() and clk_enable()? [MK]Many IPs on DaVinci VPFE would require vpss master clock. So it is better to do the way I have done in my patch. So it is expected that clk_get, clk_enable etc are called from other drivers as well. OK, then you are expecting to add clkdev nodes for the other devices as well. That's ok. However, you still haven't answered my original question. AFAICT, there are no users of the clkdev nodes vpss_master and vpss_slave. Why not remove those and replace them with your new nodes instead of leaving them and adding new ones? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IR device at I2C address 0x7a
Daro ghost-rider at aster.pl writes: Hi Jean, Thank you for your answer. It is not the error message itself that bothers me but the fact that IR remote control device is not detected and I cannot use it (I checked it on Windows and it's working). After finding this thread I thought it could have had something to do with this error mesage. Is there something that can be done to get my IR remote control working? Thanks for your help in advance. Best regards Darek Hi Darek, I use a P7131 Dual with mythbuntu, and the IR remote needed special setup. While it's a slightly different model of P7131 yours, it could be worth a try. In /etc/lirc/hardware.conf I needed the lines: REMOTE_DRIVER=devinput REMOTE_DEVICE=name=saa7134* REMOTE_LIRCD_CONF=asus/mycinema.conf (remove or comment out any existing REMOTE_DEVICE entries) The device name (with wildcard) matches on input device name (rather than using numbered input which could change on reboot) The remote config (IR codes for remote) go in: /usr/share/lirc/remotes/asus/mycinema.conf The button mappings are in another file associated with the specific application (lircrc for mythtv). Dave W dniu 06.01.2010 15:39, Jean Delvare pisze: Hi Darek, Adding LMML to Cc. On Wed, 23 Dec 2009 18:10:08 +0100, Daro wrote: I have the problem you described at the mailing list with Asus MyCinema-P7131/P/FM/AV/RC Analog TV Card: IR remote control is not detected and i2c-adapter i2c-3: Invalid 7-bit address 0x7a error occurs. lspci gives the following output: 04:00.0 Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1) dmesg output I enclose in the attachment. I use: Linux DOMOWY 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:02:15 UTC 2009 x86_64 GNU/Linux I would be gratefull for the help on that. (...) subsystem: 1043:4845, board: ASUS TV-FM 7135 [card=53,autodetected] (...) i2c-adapter i2c-3: Invalid 7-bit address 0x7a saa7133[0]: P7131 analog only, using entry of ASUSTeK P7131 Analog This error message will show on virtually every SAA713x-based board with no known IR setup. It doesn't imply your board has any I2C device at address 0x7a. So chances are that the message is harmless and you can simply ignore it. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Hi Terry,
Thanks for your comments, my responses are inline below.
Hi,
You can check the dmesg output to verify which XCEIVE
firmware/SCODE is using.
For examples,
(1). DVB-T 7MHz bandwidth, frequency=177.5MHz and BASE F8MHZ/DTV7
firmware is using,
SCODE SCODE DTV7 ZARLINK456/HAS_IF_5260
[ 266.008596] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3),
id .
[ 267.098011] xc2028 0-0061: Loading firmware for type=D2633 DTV7 (90),
id .
[ 267.48] xc2028 0-0061: Loading SCODE for type=DTV7 ZARLINK456
SCODE HAS_IF_5260 (6280), id .
(2). DVB-T 7MHz bandwidth, frequency=177.5MHz and BASE F8MHZ/DTV78
firmware is using,
SCODE DTV78 ZARLINK456/SCODE HAS_IF_4760
[ 1089.192377] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3),
id .
[ 1090.265461] xc2028 0-0061: Loading firmware for type=D2633 DTV78
(110), id .
[ 1090.278523] xc2028 0-0061: Loading SCODE for type=DTV78 ZARLINK456
SCODE HAS_IF_4760 (62000100), id .
My firmware load logging looks as follows
[ 376.312248] xc2028 4-0061: Loading firmware for type=BASE F8MHZ (3), id
.
[ 380.832015] xc2028 4-0061: Loading firmware for type=D2633 DTV7 (90),
id .
[ 380.912010] xc2028 4-0061: Loading SCODE for type=DTV6 QAM DTV7 DTV78
DTV8 ZARLINK456 SCODE HAS_IF_4760 (620003e0), id .
Terry
2010/1/7 Terry Wu terrywu2...@gmail.com:
Hi,
The following codes in the 6MHz patch are not for 6MHz.
Please read the mchehab's comments.
1.28 /*
1.29 - * We must adjust the offset by 500kHz in two
cases in order
1.30 - * to correctly center the IF output:
1.31 - * 1) When the ZARLINK456 or DIBCOM52 tables
were
explicitly
1.32 - * selected and a 7MHz channel is tuned;
1.33 - * 2) When tuning a VHF channel with DTV78
firmware.
1.34 + * We must adjust the offset by 500kHz when
1.35 + * tuning a 7MHz VHF channel with DTV78 firmware
1.36 + * (used in Australia)
1.37 */
1.38 - if (((priv-cur_fw.type DTV7)
1.39 - (priv-cur_fw.scode_table (ZARLINK456 |
DIBCOM52))) ||
1.40 - ((priv-cur_fw.type DTV78) freq
47000))
1.41 + if ((priv-cur_fw.type DTV78) freq
47000)
1.42 offset -= 50;
BTW, the DTV7 firmware or DTV78 firmware is using if you are tuning
a VHF channel (frequency 470MHz).
And the above mchehab's new codes will not do offset -= 50;
if DTV7 firmware is using.
Terry
Mauro's new code does the 50 offset unconditionally for DTV7 by
setting offset = 225, not just when the ZARLINK456 or DIBCOM52 tables
were explicitly selected. This change is what appears to cause issues for
me.
The working (old) code used to do something like the following for DTV7
+ offset = 275;
...
+ if (((priv-cur_fw.type DTV7)
+(priv-cur_fw.scode_table (ZARLINK456 | DIBCOM52))) ||
+ ((priv-cur_fw.type DTV78) freq 47000))
offset -= 50;
My firmware type is DTV7, but priv-cur_fw.scode_table == 129 == SCODE,
which does not match the test for (ZARLINK456 | DIBCOM52), so offset is
left as 275 which works perfectly for me.
The current hg tip which does not work well for me now does a
- else if (priv-cur_fw.type DTV7)
- offset = 225;
including the 500kHz offset adjustment in the initial value. This causes
a lot of stuttering, corruption etc for me.
My patch set proposes to revert back to the original working code, but
still implement the change from testing against ATSC to DTV6 for (Taiwan?)
That is
diff -r 32b2a1875752 linux/drivers/media/common/tuners/tuner-xc2028.c ---
a/linux/drivers/media/common/tuners/tuner-xc2028.c Fri Nov 20 12:47:40
2009 +0100
+++ b/linux/drivers/media/common/tuners/tuner-xc2028.c Fri Nov 27 10:29:22
2009 +1100
@@ -936,7 +936,7 @@
*/
if (new_mode == T_ANALOG_TV) {
rc = send_seq(priv, {0x00, 0x00});
- } else if (priv-cur_fw.type ATSC) {
+ } else if (priv-cur_fw.type DTV6) {
offset = 175;
} else {
offset = 275;
Were you able to test my proposed patches to see if they continue to work
for you
-Rob
2010/1/7 Terry Wu terrywu2...@gmail.com:
Hi,
And the 6MHz patch you mentioned is a wrong patch.
http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0
+ if (priv-cur_fw.type DTV6)
+ offset = 175;
+ if (priv-cur_fw.type DTV7)
+ offset = 225;
+ else /* DTV8 or DTV78 */
+ offset = 275;
and latest
Kworld 315U and SAA7113?
After some work I have finally gotten the analog inputs to work with the Kworld 315U device. I have attached the changes/updates to the em28xx driver. Note: I still don't have analog sound working yet.. I am hoping someone can comment on the changes in saa7115.c. I added a s_power routine to reinitialize the device. The reason I am reinitializing this device is because 1. I cannot keep both the LG demod and the SAA powered on at the same time for my device 2. The SAA datasheet seems to suggest that after a reset/power-on the chip needs to be reinitialized. 3. Reinitializing causes the analog inputs to work correctly. Here's what is says in the SAA7113 datasheet.. Status after power-on control sequence VPO7 to VPO0, RTCO, RTS0 and RTS1 are held in high-impedance state after power-on (reset sequence) a complete I2C-bus transmission is required ... The above is really suppose to be arranged horizontally in 3 columns. Anyways, the last part describes that a complete I2C bus transmission is required This is why I think the chip needs to be reinitialized. Last thing is that the initialization routing uses these defaults: state-bright = 128; state-contrast = 64; state-hue = 0; state-sat = 64; I was wondering if we should just read the back the values that were initialized by the initialization routine and use those values instead.The reason is because it seems like the different SAA's use slightly different values when initializing. Thanks, Franklin Meng mydiff1 Description: Binary data
Re: Compro VideoMate U80 DVB-T USB 2.0 High Definition Digital TV Stick
Jan Hoogenraad wrote: Can you give us the USB ID (type on the command line: lsusb, and report the output) The U90 has a RTL2831 in it. More info on the driver on: http://www.linuxtv.org/wiki/index.php/Rtl2831_devices Hi Jan USB ID is : 185b-0150 Compro I built the driver as per the link but the device does not initialise. Tested using an Ubuntu Studio Karmic installation with two afatech 9015 USB devices connected ok Thanks drappa drappa wrote: Hi All http://www.comprousa.com/en/product/u80/u80.html I'd be grateful if anyone can tell me if this device is supported yet, and if so, any pointers to getting it working. Thanks Drappa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compro VideoMate U80 DVB-T USB 2.0 High Definition Digital TV Stick
So: it is a Realtek 2831 device. Please first check /lib/udev/rules.d/50-udev-default.rules. There seems to be a generic problem with Karmac there. Look at http://ubuntuforums.org/showthread.php?t=1327337 which gives solution for the problem by installing a new rule:- /etc/udev/rules.d/50-udev.rules Under Ubuntu Karmac, I have heard that the anttip/rtl2831u driver works (alas without IR support) with this workaround. Of the jhoogenraad/rtl2831-2 I have no confirmation yet. http://ubuntuforums.org/showthread.php?t=960113 Which one have you downloaded ? drappa wrote: Jan Hoogenraad wrote: Can you give us the USB ID (type on the command line: lsusb, and report the output) The U90 has a RTL2831 in it. More info on the driver on: http://www.linuxtv.org/wiki/index.php/Rtl2831_devices Hi Jan USB ID is : 185b-0150 Compro I built the driver as per the link but the device does not initialise. Tested using an Ubuntu Studio Karmic installation with two afatech 9015 USB devices connected ok Thanks drappa drappa wrote: Hi All http://www.comprousa.com/en/product/u80/u80.html I'd be grateful if anyone can tell me if this device is supported yet, and if so, any pointers to getting it working. Thanks Drappa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
