Re: [PATCH] drivers/media/dvb/dvb-core/dvb_net.c: use %pM to show MAC address

2010-01-07 Thread David Miller
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)]

2010-01-07 Thread Benoît Pourre
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

2010-01-07 Thread Terry Wu
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

2010-01-07 Thread Terry Wu
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

2010-01-07 Thread Terry Wu
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

2010-01-07 Thread Terry Wu
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

2010-01-07 Thread Karicheri, Muralidharan
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

2010-01-07 Thread Kevin Hilman
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: DTV2000 H Plus issues

2010-01-07 Thread istva...@mailbox.hu
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


[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK

2010-01-07 Thread Hans Verkuil
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

2010-01-07 Thread Devin Heitmueller
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

2010-01-07 Thread istva...@mailbox.hu
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

2010-01-07 Thread Karicheri, Muralidharan
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

2010-01-07 Thread Kevin Hilman
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

2010-01-07 Thread Jan Hoogenraad

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

2010-01-07 Thread Karicheri, Muralidharan
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

2010-01-07 Thread Karicheri, Muralidharan
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

2010-01-07 Thread dave_a
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

2010-01-07 Thread Robert Lowery
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?

2010-01-07 Thread Franklin Meng
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

2010-01-07 Thread drappa

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

2010-01-07 Thread Jan Hoogenraad

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