Re: tvtime audio vs pcHDTV-3000 card and pvHDTV-1.6 software

[George Anzinger <george@mvista.com>]

[-- Attachment #1: Type: text/plain, Size: 2782 bytes --]

Heavens, no need to clean the tree at all.  Just add "-X <file> to your diff.  I 
have attached what I use for <file>.  It is likely over kill, but should do...

-g

Gene Heskett wrote:
> Greetings;
> 
> I've spent a goodly part of the last 3 hours rebooting, to find out 
> where this audio control function died, and I think now I can point 
> an accusatory finger at the 2.6.11.2 patch with some degree of 
> certainty.
> 
> The scenario goes like this:
> 
> reboot to 2.6.11-rc5, everything works flawlessly except the 1394 
> stuff, that kernel didn't have it built in yet.
> 
> reboot to 2.6.11+bk-ieee1394.patch  everything works flawlessly
> 
> reboot to 2.6.11.1+bk-ieee1394.patch everything works flawlessly
> 
> reboot to 2.6.11.2+bk-ieee1394.patch tvtime has no volume control, and 
> the sound gets very very tinny about 1 second after it starts
> 
> This scenario continues up to and includeing 2.6.11.4.
> 
> So now my next question is, how to I clean up those src trees so that 
> a diff actually outputs only the src code differences, thereby 
> allowing a simple diff -urN (or whatever is the recommended command 
> line to do a recursive diff on the whole maryann) to disclose the 
> real diffs.  In other words, is a simple 'make clean' sufficient?
> 
> I got the impression from a comment that was made, that quite a body 
> of work was actually done, in the i2c area, that somehow does not 
> show in the changelog, nor in that simple little 10 line patch that 
> was 2.6.11.2.  And how that little patch could be responsible for 
> breaking this boggles what tiny little miniscule piece of a mind I 
> have left at this point.
> 
> If thats the case, then how did it get into my src code tree since the 
> exact same 2.6.11.tar.gz was used as the base for applying each of 
> the incrementals to each of the src trees I now have sitting 
> in /usr/src?  Good question that...
> 
> Unforch, the 2.6.11 plain tree has not, in this case been built yet as 
> it got accidently nuked by a missfire of my 'buildit26' script, which 
> normally moves a base version tree out of the way before it unpacks a 
> fresh copy, and then renames that tree to be the current version and 
> then restores the base tree to its original name.
> 
> Thats not the one I want to use as the 'gold standard' anyway. 
> 2.6.11.1 works, and 2.6.11.2 doesn't.  So at this point, 2.6.11.1 is 
> the 'gold standard'.
> 
> But, both the 2.6.11.1 and the 2.6.11.2 trees are as built, and the
> diff I got was far larger than forgetting to apply the 
> bk-ieee1394.patch to one of them would account for.  Many tens of 
> kilobytes in fact.
> 
> Please throw me a bone here folks.
> 

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/

[-- Attachment #2: patch.exclude --]
[-- Type: text/plain, Size: 532 bytes --]

*.o
*.i
.*
*.*~
*~
*.rej
*.orig
*.orig.*
#*
*#
*.ver
ETAGS
TAGS
tags
*.map
*.s
*.a
*X
*Y

*.*X
*.*Y
SCCS
CVS
*.*,*
dwarf2-defs.h
kconfig
configs.c
defconfig
mkdep
split-include
tkparse
vmlinux
consolemap_deftbl.c
tkparse.c
classlist.h
crc32table.h
devlist.h
config
autoconf.h
compile.h
version.h
kconfig.tk
soundmodem
defkeymap.c
patest
asm
boot
conmakehash
gen-devlist
modversions.h
elfconfig.h
asm_offsets.h
*.old
cscope.*
*.so
gen_crc32table
docproc
fixdep
kallsyms
mk_elfconfig
modpost
pnmtologo
initramfs_data.*
gen_init_cpio