[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