Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Hi, Please refer to the XCEIVE document. And set the correct SCODE. >> 380.912010] xc2028 4-0061: Loading SCODE for >>type=DTV6 QAM DTV7 DTV78 >> (What is this type ???) >>DTV8 ZARLINK456 SCODE HAS_IF_4760 >>(620003e0), id 00000000. Terry 2010/1/8 Terry Wu : > Hi, > > XCEIVE's documents are attached. > > Terry > > 2010/1/8 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 >> 0000. >> [ 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 : >>>> 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 == 1<<29 == SCODE, >> which does not match the test for (ZARLINK456 | DIBCOM52), so offset
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 : > 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 : >> 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 : >>> Hi, >>> >>> The 6MHz patch is for Taiwan only. >>> It should not change anything for 7MHz and 8MHz. >>> >>> Terry >>> >>> 2010/1/7 Robert Lowery : >>>>> 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 >>>>>>
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 : > 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 : >> Hi, >> >> The 6MHz patch is for Taiwan only. >> It should not change anything for 7MHz and 8MHz. >> >> Terry >> >> 2010/1/7 Robert Lowery : >>>> 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 >>>>> >> > >>>>> >> > 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 L
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 = 2750000; Terry 2010/1/7 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 : >>> 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 >>>> >> > >>>> >> > 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 f
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 : >> 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 >>> >> > >>> >> > 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. >>
Re: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T
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 :
>
>> 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
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 : > 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
