[linux-dvb] [-mm PATCH] v4l: add dvb support for dvico fusionhdtv3 gold-T and fix cx88-dvb for kconfig

Mac Michaels wmichaels1 at earthlink.net
Tue Jul 5 23:48:31 CEST 2005


On Tuesday 05 July 2005 01:30 pm, Michael Krufky wrote:
> Mac Michaels wrote:
> >This is going to take a bit of explanation. Short answer
> > - I am correct and it seems to work anyway.
> >
> >There are two control registers that control the
> > detection of start of packet (SOP) - TS_HW_SOP_CNTRL
> > and TS_SOP_STAT. Both of these registers are documented
> > in the CX23880 data sheet.
> >
> >cx_write(TS_HW_SOP_CNTRL,47<<16|188<<4|0x00);
> >
> >is interpreted as Packet start byte value is 47, Packet
> > length is 188, 0 start bytes must be received before
> > declaring the packet stream in sync. Logic indicates
> > that if 0 start bytes must be received then the value
> > of the start byte does not matter. It is in sync all
> > the time. This is a bug and should be fixed.
> >
> >Changing the line to:
> >
> >cx_write(TS_HW_SOP_CNTRL,47<<16|188<<4|0x01);
> >
> >will appear to work since somewhere in a small number of
> > packets it is likely that the decimal 47 will appear.
> > It does not need to be the first byte. I only needs to
> > appear once to have the stream declared in sync. Actual
> > start of packet is done by another hardware signal.
> >
> >How does this get in sync? That is where TS_SOP_STAT is
> > used.
> >
> >cx_write(TS_SOP_STAT, 0<<16 | 0<<14 | 1<<13 | 0<<12);
> >
> >Bit 16 selects active high polarity. Bits 15,14 select
> > SOP detects rising edge of TSSCP input, BIT 13 selects
> > width of SOP as byte in serial mode (FusionHDTV 3 Gold
> > uses serial mode), Bit 12 was used when I was
> > experimenting and may be removed as the default is 0.
> > This code does not need to be changed in the driver.
> >
> >An interesting option for bits 15,14 is 3. This uses the
> > Packet start byte value set in the TS_HW_SOP_CNTRL
> > register to locate the start of a packet. This is
> > intended for hardware that does not have connection to
> > TSSOP or TSVALERR suitable for detecting the start of a
> > packet. It is interesting for testing the value of the
> > SOP byte value.
> >
> >Here are two variations I tried:
> >
> >cx_write(TS_HW_SOP_CNTRL,47<<16|188<<4|0x01);
> >cx_write(TS_SOP_STAT, 0<<16 | 3<<14 | 1<<13 | 0<<12);
> >Result: no packets detected.
> >
> >cx_write(TS_HW_SOP_CNTRL,0x47<<16|188<<4|0x01);
> >cx_write(TS_SOP_STAT, 0<<16 | 3<<14 | 1<<13 | 0<<12);
> >Result: packets detected and normal operation of mythtv.
> >
> >If you can verify that the other frontends use the
> > normal default value for the packet start byte,  you
> > could do this:
> >
> >-              
> > cx_write(TS_HW_SOP_CNTRL,47<<16|188<<4|0x00); +        
> >       cx_write(TS_HW_SOP_CNTRL,0x47<<16|188<<4|0x01);
>
> Mac-
>
> cx88 datasheet says that 47d is the correct start byte. 
> Originaly Mauro and I thought that you may have either
> (a) misread the datasheet, or that maybe (b) the cx88
> people made a mistake on the datasheet, and should have
> instead indicated 0x47 as the start byte.  

Hmm - what is the date on your data sheet? Mine is August 
08/26/2002. Figures 2-36 and 2-37 on page 2-80 show the 
start byte as 0x47 twice on each of the timing diagrams. 
The HW SOP Control on page 6-99 lists it as d47. The 
CX23880 default value is not consistent :-(  

> I will assume 
> that you obtained your information from DViCO, which
> leads me to the next question:

I also saw that the recommended value is 0x47 is some ATSC 
specification that I read. I do not recall what document 
that was.

> Perhaps the datasheet is correct, and you are also
> correct. This would mean to keep the current setting for
> other boards, and follow your advice for the fusionhdtv3
> gold boards.   In this case, are you telling me that for
> the lgdt3302 frontend, that the start byte is 0x47
> instead of 47d, as previously defined?  Maybe lgdt
> properties are different from other frontends?

My test proves that lgdt3302 uses 0x47 as the start byte 
value. I can not speak for other boards as the start byte 
is not a part of the transmitted data stream. The start 
byte is inserted under control of the frontend hardware.

> If this is the case, then I will try to revise cx88-mpeg
> such that it will test for (frontend==lgdt3302) instead
> of  (core->board == CX88_BOARD_DVICO_FUSIONHDTV_3_GOLD)
> ... this would probably be more appropriate, although we
> may have to stick with the board condition, as I dont
> think cx88-mpeg has access to the frontend name ... I'll
> have to look that up.
>
> Is there anything on the lgdt3302 to support this?  (i
> understand that you cannot show me, so I am asking you to
> look this up)

Yes. "The data segment sync is set to 47H." This sentence 
appears in both VSB and QAM sections. There is no reference 
to a decimal value of 47 anywhere.

> Thank you.

Also important to note is that the code as it was originally 
written before lgdt3302 was added does not actually use the 
value of the start byte. The 0 value in the start byte 
count causes the value of the start byte to be ignored.

-- Mac




More information about the linux-dvb mailing list