Mailing List Archive

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-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel