I do not approve this patch. Mac Michaels
--- linux-2.6.13/drivers/media/video/cx88/cx88-mpeg.c 2005-07-05 00:34:56.000000000 +0000
+++ linux/drivers/media/video/cx88/cx88-mpeg.c 2005-07-05 00:47:22.000000000 +0000
@@ -73,11 +73,11 @@
cx_write(TS_GEN_CNTRL, 0x0040 | dev->ts_gen_cntrl);
udelay(100);
cx_write(MO_PINMUX_IO, 0x00);
- if (core->board == CX88_BOARD_DVICO_FUSIONHDTV_3_GOLD_Q) {
[1]- cx_write(TS_HW_SOP_CNTRL,0x47<<16 | 188<<4 | 0x00);
[2]+ cx_write(TS_HW_SOP_CNTRL,47<<16|188<<4|0x00);
+ if ((core->board == CX88_BOARD_DVICO_FUSIONHDTV_3_GOLD_Q) ||
+ (core->board == CX88_BOARD_DVICO_FUSIONHDTV_3_GOLD_T)) {
cx_write(TS_SOP_STAT, 0<<16 | 0<<14 | 1<<13 | 0<<12);
} else {
[3]- cx_write(TS_HW_SOP_CNTRL,47<<16|188<<4|0x00);
cx_write(TS_SOP_STAT,0x00);
}
cx_write(TS_GEN_CNTRL, dev->ts_gen_cntrl);
I added numbers in braces for reference in the following discussion.
It appears that Michael thought lines [1] and [3] were identical.
He simplified the code by combining them in one place at line [2].
Look carefully at the hexadecimal 0x47 constant in the middle of line [1]
It the value required for FusionHDTV 3 Gold cards. Lines [2] and [3]
contain the decimal 47 constant. This part of the patch should not
be applied.
As an aside, I wonder if all cards should use the 0x47 constant as it is
listed as the default start byte value for ATSC. It is not actually transmitted
but is generated by the LGDT3302 chip. I guess other chips could use
a different value if they want to. That is why I chose not to change the
code for cards other than FusionHDTV 3 Gold.
-- Mac
On Tuesday 05 July 2005 07:53 am, Michael Krufky wrote:
> Johannes Stezenbach wrote:
> >Michael Krufky wrote:
> >>I'm happy to let you know that I have successfully
> >> gotten digital video working (only with 8vsb, not
> >> qam256). I have already applied the changes into
> >> video4linux cvs and the dvb-pll changes into linuxtv
> >> cvs. In addition, I solved the problem where cx88-dvb
> >> automatically loads up mt352, or51132, cx22702 and
> >> lgdt3302 no matter which one is needed. As of now,
> >> only the correct module will be loaded up when
> >> modprobing cx88-dvb. (I have applied the same fix
> >> with saa7134).
> >
> >Can you outline how? IIRC we wanted to avoid an #ifdef
> > mess so we just statically depend on all frontends.
> > This was considered OK as the frontend drivers are
> > usually tiny.
>
> Johannes-
>
> The change that I am talking about only applies to
> loading frontends through cx88-dvb and saa7134-dvb (in
> video4linux).
>
> I must make this quick, because I am about to leave the
> house to go to the office... What I have done is: (in
> video4linux) I renamed the #ifdef HAVE_CX22702 to #ifdef
> CONFIG_DVB_CX22702 ... ...I also removed the #define
> HAVE_CX22702 (not only for cx22702 -- i am just using
> this as an example) from the top of cx88-dvb.c ... This
> allows Kconfig to decide what frontend-specific code gets
> included in cx88-dvb. Of course, when compiling from cvs
> or from a snapshot, the Makefile will include all code by
> default. It is easier to understand if you look at the
> attached patch.
>
> I have not sent the attached patch to Andrew or LKML yet.
>
> I'd like permission to include your sign-off on this,
> since it changes files in both trees (dvb-pll changes
> have already been committed to linuxtv cvs, and all other
> changes have been committed to v4l cvs). I will ask
> Mauro for his sign-off as well when I see him in irc
> later on.
>
> This patch depends on:
>
> dvb-frontend-add-driver-for-lgdt3302.patch (added to -mm
> tree) [PATCH] v4l: add DVB support for DViCO FusionHDTV3
> Gold-Q (on lkml, still pending)
>
> If you wish to test how this applies against -mm, start
> off with 2.6.13-rc1-mm1, then:
>
> 1) apply dvb-frontend-add-driver-for-lgdt3302.patch
> 2) apply [PATCH] v4l: add DVB support for DViCO
> FusionHDTV3 Gold-Q 3) apply [PATCH] v4l: add TerraTec
> Cinergy 1400 DVB-T (also on lkml) 4) apply the patch
> attached to this email last.
>
> (patch #3 has also been sent to andrew. (still pending)
> The attached patch doesn't depend on this, but in order
> for everything to apply cleanly, apply it in the order
> listed)
