On Sun, 2009-02-15 at 22:31 -0500, Jeff Campbell wrote: > Hi Andy, > > I updated to the latest mainline as of this morning to catch the fixes > you and Hans recently submitted. > > I had a strange problem tonight. Over and over I rebooted and I had > no audio on cx18-0. Many times I had no audio on cx18-1 but a few > times cx18-1 audio was fine. These were both soft and hard reboots. > > After a number of attempts, I did an rmmod and a modprobe and low and > behold I had audio back. I rebooted again after that and audio was > fine.
So it's fair to say a difference is a busy PCI bus at boot versus one that isn't. > I was not doing anything unusual in between, in fact I launch a fixed > config at boot so conditions were identical each time I booted the > system. > > I did try adjusting a few settings by hand on a few boots (would > revert to fixed config on next boot) and it made no difference. > > Any idea what might be causing that? It seems worse than previous > releases, which would occasionally result in no audio on cx18-0 but > cx18-1 was almost always fine. 1. I have no documentation on the CX18_AUDIO_ENABLE register, and writing to it successfully, but not multiple times in a row, seems like it might be necessary. It's behavior is really not straightforward when I check it with v4l2-dbg, but various bits change when you write to some other bits. I changed a couple of calls to write() that register to write_expect() type calls. That may be making the difference. 2. The APU interaction with the CPU is a black box to me. The only thing I'm guessing I can really safely do independently of the CPU is start it up, reset it, and shut it down. I did an additional RESETAI of the APU after the second firmware load. Maybe that matters. 3. I need to reinvestigate the cx18_vapi(cx, CX18_CPU_SET_MISC_PARAMETERS, 2, s->handle, 12); call in cx18-streams.c. It's audio related according to open source ivtv documentation, and it came from the port from ivtv. I'm not sure it's a valid thing to do. It now only gets called on the first analog capture stream starting for a card, and won't be called again until all analog captures stop and a new one get started. 4. Beyond that, I think I need to get CX23418 hardware I2C masters working as opposed to the i2c_algo_bit bit banging protocol, as the former is much less PCI bus intensive. That may help with analog tuner issues, and CS5345 baseband audio, but not much else. 5. I need to lengthen the GPIO reset assertion period for HVR-1600 cards. It should be 100 ms not 40 ms, to ensure the CX24227 is reset and not screwing up the I2C bus and thus baseband audio from the CS5345. Sorry I haven't been repsonding to much. I've got to convert the cx18 driver to the v4l2_device/subdevice framework in advance of a kernel release deadline so I2C subsystem objective can be met to get rid of some system I2C headaches. Unfortunately that doesn't carry much immediate benefit as far as cx18 drivers issues are concerned. Regards, Andy > -Jeff _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
