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. > > 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
