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: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T

2009-06-23 Thread Terry Wu
Hi,

1. The CX23885's  GPIO 23 thru 19 - On the cx25840 a/v core is not
implemented yet.
You can find the following codes in the cx23885-core.c :
/* Mask represents 32 different GPIOs, GPIO's are split into multiple
 * registers depending on the board configuration (and whether the
 * 417 encoder (wi it's own GPIO's) are present. Each GPIO bit will
 * be pushed into the correct hardware register, regardless of the
 * physical location. Certain registers are shared so we sanity check
 * and report errors if we think we're tampering with a GPIo that might
 * be assigned to the encoder (and used for the host bus).
 *
 * GPIO  2 thru  0 - On the cx23885 bridge
 * GPIO 18 thru  3 - On the cx23417 host bus interface
 * GPIO 23 thru 19 - On the cx25840 a/v core
 */
void cx23885_gpio_set(struct cx23885_dev *dev, u32 mask)
{
if (mask  0x7)
cx_set(GP0_IO, mask  0x7);

if (mask  0x0007fff8) {
if (encoder_on_portb(dev) || encoder_on_portc(dev))
printk(KERN_ERR
%s: Setting GPIO on encoder ports\n,
dev-name);
cx_set(MC417_RWD, (mask  0x0007fff8)  3);
}

/* TODO: 23-19 */
if (mask  0x00f8)
printk(KERN_INFO %s: Unsupported\n, dev-name);
}

void cx23885_gpio_clear(struct cx23885_dev *dev, u32 mask)
{
if (mask  0x0007)
cx_clear(GP0_IO, mask  0x7);

if (mask  0x0007fff8) {
if (encoder_on_portb(dev) || encoder_on_portc(dev))
printk(KERN_ERR
%s: Clearing GPIO moving on encoder ports\n,
dev-name);
cx_clear(MC417_RWD, (mask  0x7fff8)  3);
}

/* TODO: 23-19 */
if (mask  0x00f8)
printk(KERN_INFO %s: Unsupported\n, dev-name);
}

void cx23885_gpio_enable(struct cx23885_dev *dev, u32 mask, int asoutput)
{
if ((mask  0x0007)  asoutput)
cx_set(GP0_IO, (mask  0x7)  16);
else if ((mask  0x0007)  !asoutput)
cx_clear(GP0_IO, (mask  0x7)  16);

if (mask  0x0007fff8) {
if (encoder_on_portb(dev) || encoder_on_portc(dev))
printk(KERN_ERR
%s: Enabling GPIO on encoder ports\n,
dev-name);
}

/* MC417_OEN is active low for output, write 1 for an input */
if ((mask  0x0007fff8)  asoutput)
cx_clear(MC417_OEN, (mask  0x7fff8)  3);

else if ((mask  0x0007fff8)  !asoutput)
cx_set(MC417_OEN, (mask  0x7fff8)  3);

/* TODO: 23-19 */
}

2. Also, I can not find GPIO functions in the cx25840-core.c

Something missing or unfinished ?

Best Regards,
Terry

2009/6/23 Hans Verkuil hverk...@xs4all.nl:

 On Tue, 2009-06-23 at 11:39 +0800, Terry Wu wrote:
 Hi,

     I add the following codes in the cx23885_initialize() of
 cx25840-core.c:
      /* Drive GPIO2 (GPIO 19~23) direction and values for DVB-T */
      cx25840_and_or(client, 0x160, 0x1d, 0x00);
      cx25840_write(client, 0x164, 0x00);

     Before that, the tuning status is 0x1e, but 0 service found.
     Now, I can watch DVB-T (Taiwan, 6MHz bandwidth).

     And if you are living in Australia, you should update the
 tuner-xc2028.c too:
     
 http://tw1965.myweb.hinet.net/Linux/v4l-dvb/20090611-TDA18271HDC2/tuner-xc2028.c

 Best Regards,
 Terry


 Hans,

 As I think of potential ways to handle this, I thought we may need to
 add a v4l2_subdev interface for setting and reading GPIO's.

 There is already an s_gpio in the core ops. It would be simple to add a
 g_gpio as well if needed.

 It is not a good idea to directly control GPIO pins from within a subdev
 driver for the simple reason that the subdev driver has no idea how its
 gpio pins are hooked up. This should really be done from the v4l driver
 itself. If you need a notification from the subdev that the v4l driver
 needs to take some action, then the subdev can send a notification through
 the notify function in v4l2_device. That's currently used by one subdev
 driver that requires that the v4l driver toggles a GPIO pin at the right
 time.

 Regards,

          Hans

 A CX23418 based board has a Winbond W8360x GPIO IC connected via I2C.
 When I get to writing a v4l2_subdevice driver for that, it will need
 such an internal interface as well.

 Thoughts?

 Regards,
 Andy




 --
 Hans Verkuil - video4linux developer - sponsored by TANDBERG


--
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: Leadtek Winfast DTV-1000S

2009-06-19 Thread Terry Wu
Hi,

[9.916022] saa7134 :05:01.0: firmware: requesting 
dvb-fe-tda10048-1.0.fw
[   10.020209] tda10048_firmware_upload: Upload failed. (file not found?)

The dvb-fe-tda10048-1.0.fw is needed.
You can get it from the following links:
http://tw1965.myweb.hinet.net/Linux/firmware.tar.gz
http://tw1965.myweb.hinet.net/Linux/Firmware.txt
http://tw1965.myweb.hinet.net/

2009/6/19 James Moschou james.mosc...@gmail.com:
 OK after adding 'options saa7134 card=156' to /etc/modprobe.d/modprobe.conf
 it loads correctly, thanks Brad.

 dmesg:

 [    8.438243] Linux video capture interface: v2.00
 [    8.606434] nvidia :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16
 [    8.606440] nvidia :01:00.0: setting latency timer to 64
 [    8.607114] NVRM: loading NVIDIA UNIX x86_64 Kernel Module
 185.18.14  Wed May 27 01:23:47 PDT 2009
 [    8.626542] input: PC Speaker as /devices/platform/pcspkr/input/input6
 [    8.659879] iTCO_vendor_support: vendor-support=0
 [    8.26] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.05
 [    8.666736] iTCO_wdt: Found a ICH9 TCO device (Version=2, TCOBASE=0x0460)
 [    8.666811] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
 [    8.742132] saa7130/34: v4l2 driver version 0.2.15 loaded
 [    8.742181] saa7134 :05:01.0: PCI INT A - GSI 19 (level, low) - IRQ 
 19
 [    8.742186] saa7130[0]: found at :05:01.0, rev: 1, irq: 19,
 latency: 32, mmio: 0xfb002000
 [    8.742191] saa7130[0]: subsystem: 107d:6655, board: Hauppauge
 WinTV-HVR1110r3 DVB-T/Hybrid [card=156,insmod option]
 [    8.742214] saa7130[0]: board init: gpio is 22000
 [    8.852862] HDA Intel :00:1b.0: PCI INT A - GSI 22 (level,
 low) - IRQ 22
 [    8.852908] HDA Intel :00:1b.0: setting latency timer to 64
 [    8.916022] saa7130[0]: i2c eeprom 00: 7d 10 55 66 54 20 1c 00 43
 43 a9 1c 55 d2 b2 92
 [    8.916031] saa7130[0]: i2c eeprom 10: 00 ff 82 0e ff 20 ff ff ff
 ff ff ff ff ff ff ff
 [    8.916039] saa7130[0]: i2c eeprom 20: 01 40 01 01 01 ff 01 03 08
 ff 00 8a ff ff ff ff
 [    8.916046] saa7130[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [    8.916054] saa7130[0]: i2c eeprom 40: ff 35 00 c0 00 10 03 02 ff
 04 ff ff ff ff ff ff
 [    8.916062] saa7130[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [    8.916069] saa7130[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [    8.916077] saa7130[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [    8.916085] saa7130[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [    8.916092] saa7130[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [    8.916100] saa7130[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [    8.916108] saa7130[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [    8.916115] saa7130[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [    8.916123] saa7130[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [    8.916131] saa7130[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [    8.916138] saa7130[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [    8.916148] tveeprom 0-0050: Encountered bad packet header [ff].
 Corrupt or not a Hauppauge eeprom.
 [    8.916150] saa7130[0]: warning: unknown hauppauge model #0
 [    8.916151] saa7130[0]: hauppauge eeprom: model=0
 [    8.980528] Chip ID is not zero. It is not a TEA5767
 [    8.980592] tuner 0-0060: chip found @ 0xc0 (saa7130[0])
 [    9.016010] tda8290: no gate control were provided!
 [    9.016080] tuner 0-0060: Tuner has no way to set tv freq
 [    9.016086] tuner 0-0060: Tuner has no way to set tv freq
 [    9.016171] saa7130[0]: registered device video0 [v4l2]
 [    9.016215] saa7130[0]: registered device vbi0
 [    9.016251] saa7130[0]: registered device radio0
 [    9.016387] rt2400pci :05:00.0: PCI INT A - GSI 20 (level,
 low) - IRQ 20
 [    9.024385] phy0: Selected rate control algorithm 'pid'
 [    9.028685] saa7134 ALSA driver for DMA sound loaded
 [    9.028688] saa7130[0]/alsa: Hauppauge WinTV-HVR1110r3 DVB-T/Hybrid
 doesn't support digital audio
 [    9.060205] dvb_init() allocating 1 frontend
 [    9.093967] Registered led device: rt2400pci-phy0:radio
 [    9.093980] Registered led device: rt2400pci-phy0:quality
 [    9.150392] lp0: using parport0 (interrupt-driven).
 [    9.174892] tda18271 0-0060: creating new instance
 [    9.184029] TDA18271HD/C1 detected @ 0-0060
 [    9.211513] Adding 6024332k swap on /dev/sda5.  Priority:-1
 extents:1 across:6024332k
 [    9.588014] DVB: registering new adapter (saa7130[0])
 [    9.588018] DVB: registering adapter 0 frontend 0 (NXP TDA10048HN DVB-T)...
 [    9.739258] EXT4 FS on sda1, internal journal on sda1:8
 [    9.916017] tda10048_firmware_upload: waiting for firmware upload
 (dvb-fe-tda10048-1.0.fw)...
 [    9.916022] saa7134 :05:01.0: firmware: requesting