Andy Walls wrote: > On Wed, 2008-07-02 at 11:10 -0300, Kevin Blair wrote: > >>> Overall, I cannot say you are wrong, you have found a causal >>> relationship. >>> >>> The question is where is the problem: the ivtv driver, the cx28540 >>> module, the i2c drivers, or the firmware image request process? (Doing >>> a great big recursive diff of the kernel and driver source code would >>> show you what's changed, but maybe not easily show what the problem is.) >> i started doing that, i dont know c++ that well so i can only go so far, >> but i went through the loaded modules and the diffrences that i found >> where minimal the changes of the order of dependant modules, and thats >> all i found so far. >> >> like for example >> --- linux-2.6.25-gentoo-r2/drivers/media/video/ivtv/ivtv.mod.c >> 2008-05-20 06:35:14.128780278 -0300 >> +++ linux-2.6.24-gentoo-r3/drivers/media/video/ivtv/ivtv.mod.c > > You can ignore the *.mod.c files; those are autogenerated as part of the > build process for modules. > > You can probably focus your efforts initially for differences in the > ivtv, cx25840, i2c-core, and i2c-algo-bit modules. Then if nothing > strike you as really different, expand your search from there. > ok, well for this, ill go with making a second copy of the sources, doing a make clean to get rid of all of the modules and files that i dont need to look at, then generate a diff source tree to work from.
this may be several days before i have anything useful so i probably wount be posting anything till end of next week, unless i come up with a cause to the issues. Kevin > >>> It still appears to be audio microcontroller related to me. I am >>> unaware of anything else that could regularly tries to change the audio >>> settings in the cx28543 chip (unless a user application is requesting it >>> - maybe turn on ioctl debugging in ivtv to see). And since resetting >>> that microcontroller makes the problem go away, it really stands out as >>> an actor in the problem. >> ok now this i need to clarify, ivtv picks loads and uses the cx2341x >> module, is the cx28544 handeled by this module or is it a seprate >> module(just to confirm) and both bleeding edge loads this aswell as the >> 2.6.23 kernel version. > > The CX25840, CX25841, CX25842, and CX25843 audio/video digitizer decoder > chips are all handled by the cx25840 module. The CX28543 chip can > handle A/V standards used the world over; the others handle subsets of > the set of worldwide A/V standards. > > The ivtv driver will load the cx28540 module for PVR cards that have a > CX2584x chip. The ivtv driver will also use the i2c-core module and > usually the i2c-algo-bit module to manipulate the registers of the > CX25843 via the I2C bus between the CX23416 and the CX25843. > > >>> Hans just made a fix to the firmware download to the AV core in the >>> CX23418 for the cx18 driver (it has a very similar core and firmware to >>> the CX28543). He noted that the firmware download had byte errors by >>> doing read backs of the bytes just written to the chip. If something >>> changed that introduces byte errors in the download of firmware to the >>> cx28540, that could obviously cause the audio microcontroller firmware >>> to act funny. >> i looked up the changes, the changes may or may not be in the copy of >> the bleeding edge driver i downloaded(done the same time frame i >> downloaded my copy), maybe he just fixed it ill download a new copy of >> bleeding edge and see if it fixes it. > > These changes only work for the cx18 driver which has a slightly > different way of manipulating the CX28543 core registers, as on the > CX23418 based boards, the CX28543 core is integrated into the CX23418 > chip and not a separate chip like on the CX23416 (ivtv) based cards. > > My point was that since it's the same CX28543 chip core and the cx18 > driver had firmware download problems, it's not outside the realm of > possibility that the firmware load in procedure in the cx28540 module is > experiencing the same sort of problem, but not correcting the errors. > > Given your troubleshooting points to a change in the source somewhere > introduced the symptoms, the firmware load routines in the cx28540 > module are at least one place in the source code where I'm guessing > things could have changed to cause the problem. Since that firmware > load also relies on I2C bus transactions, changes in the i2c modules and > the i2c routines in the ivtv module would be of interest as well. > > > > If you can find suspect change sets via source code differences, that'll > be great. If you can't, but you can verify that shutting off the > microcontroller firmware after switching to Line in 1 prevents the tinny > audio problem, that'll give me enough evidence to "get off the dime" and > look into modifications to the cx28540 module. Drivers other than ivtv > use the cx28540 module, so I wouldn't want to risk breaking something > without knowing we can fix something. > > > Regards, > Andy > >> Kevin >>> You've found a causal relationship, but the root cause is still unknown. >>> To find the root cause, I can only think of two methodologies: >>> inspection and analysis of the differences between the source code >>> version (likely a big job but it is a deterministic process), or making >>> some hypotheses and testing those hypotheses (smaller jobs but not >>> guaranteed to provide an answer). >>> >>> Regards, >>> Andy >>> >>>> Kevin >>>> >>>> Andy Walls wrote: >>>>> On Tue, 2008-07-01 at 01:34 -0300, Kevin Blair wrote: >>>>>> i dont be leave it produced the tinny audio before, but >>>>>> several things have changed (went from coax to svideo/rca input, >>>> since i cannot remember for the life of me the detail but the more i >>>> think about it im sure it was working fine and since on the slave >>>> downgrading fixes it, so i took a step back looked at the history i >>>> have, being i had the master system built since the beginning of march >>>> and did not have any issues with audio but i did have issues with >>>> sata_mv which i upgraded from a 2.6.24 kernel to a 2.6.25 kernel when it >>>> became stable at the beginning of may, so for almost 2 months it was >>>> running fine, based on the time i had it built and running and the time >>>> i upgraded to the .25 kernel, and few days after i installed the .25 >>>> kernel i was posting on the board with the issue. so it must be one of >>>> the changes from the 2.6.24 and the 2.6.25 kernel that is causing it. >>>> >>>>> Kevin, >>>>> >>>>> That is an interesting bit of information. So here's a new hypothesis: >>>>> >>>>> The audio micontroller firmware is changing the digital audio baseband >>>>> processing settings in the CX28543, corrupting the settings for line in >>>>> audio, when it thinks it detects a TV audio standard change coming in >>>>> from the tuner SIF audio input. >>>>> >>>>> If that is true, then simple solutions could be >>>>> >>>>> 1. stop the audio standard detection microcontroller firmware from >>>>> running when you've switched to an audio input other than the tuner. >>>>> >>>>> or >>>>> >>>>> 2. connect an RF TV signal source to the tuner and tune the card to an >>>>> active TV station before making the switch to the svideo or composite >>>>> input. >>>>> >>>>> >>>>> >>>>> #2 is something you can try on your own to see if it eliminates the >>>>> tinny audio. >>>>> >>>>> #1 you can try manually by commanding the ivtv driver to switch to the >>>>> line in input and then stopping the audio microcontroller by setting bit >>>>> 4 (bit 0 is the lsb, bit 7 is the msb) of register 0x803 of the CX28543 >>>>> to 0 with v4l2-dbg. v4l2-ctl --log-status will then show the audio >>>>> microcontroller as stopped. When the audio microcontroller is stopped, >>>>> nothing should be automatically changing the processing of input audio. >>>>> >>>>> The problem with doing #1, is that it takes quite a few steps to get the >>>>> audio microcontroller started properly again, and it's probably not a >>>>> good idea to try it manually. If you can verify that stopping the audio >>>>> microcontroller after switching to non-tuner inputs solves the onset of >>>>> tinny audio, then work can be done on the cx28540 driver to incorporate >>>>> this solution. >>>>> >>>>> Regards, >>>>> Andy >>>>> >>>>>> Kevin >>>>> >> >> _______________________________________________ >> ivtv-users mailing list >> [email protected] >> http://ivtvdriver.org/mailman/listinfo/ivtv-users >> > > > _______________________________________________ > ivtv-users mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-users > _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
