On Sat, 2010-04-17 at 08:18 -0400, Mark Lord wrote:
> On 16/04/10 08:59 AM, Andy Walls wrote:
> ..
> > Accesses to those are orthognal to the rest of the cx18 driver,
> > including the IRQ handler. (I agree, its hard to follow things in the
> > driver; it's very large.)
> >
> > Do note, however, t
On Sat, 2010-04-17 at 09:01 -0400, Mark Lord wrote:
> On 17/04/10 08:09 AM, Mark Lord wrote:
> ..
> > Mmm.. something is not right -- the audio is failing constantly with that
> > change.
> > Perhaps if I could dump out the registers, we might see what is wrong.
> ..
>
> When the microcontroller
On Sat, 2010-04-17 at 08:09 -0400, Mark Lord wrote:
> On 17/04/10 12:43 AM, Andy Walls wrote:
> > I had to disassemble and study some of the microcontorller firmware, and
> > then reread some documents, to figure out how all the audio detection
> > "resets" must work.
> >
> > I've just pushed some
On 17/04/10 08:09 AM, Mark Lord wrote:
..
Mmm.. something is not right -- the audio is failing constantly with that
change.
Perhaps if I could dump out the registers, we might see what is wrong.
..
When the microcontroller is reset, does it put all settings back to defaults?
I wonder if this c
On 16/04/10 08:59 AM, Andy Walls wrote:
..
Accesses to those are orthognal to the rest of the cx18 driver,
including the IRQ handler. (I agree, its hard to follow things in the
driver; it's very large.)
Do note, however, that the audio standard detection microcontroller
*does* write to the regi
On 17/04/10 12:43 AM, Andy Walls wrote:
I had to disassemble and study some of the microcontorller firmware, and
then reread some documents, to figure out how all the audio detection
"resets" must work.
I've just pushed some microcontroller reset related changes to the
cx18-audio2 repo. Please
On Thu, 2010-04-15 at 10:15 -0400, Mark Lord wrote:
> And.. one of the "fallback" recordings still had muted audio.
> Even though my script which checks for that reported "audio ok".
>
> Enough for now.. I'll hack some more on the weekend.
I had to disassemble and study some of the microcontorll
On Fri, 2010-04-16 at 09:15 -0400, Andy Walls wrote:
>
> Regards,
> Andy
>
> BTW, that's for all your testing. It's really helpful.
^^
That should be "thanks".
-Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vge
On Wed, 2010-04-14 at 00:32 -0400, Mark Lord wrote:
> On 13/04/10 09:45 PM, Andy Walls wrote:
> The syslog shows the usual "fallback" messages,
> but the audio consisted of very loud static, the kind
> of noise one gets when the sample bits are all reversed.
When in forced audio mode, the microco
On Thu, 2010-04-15 at 01:16 -0400, Mark Lord wrote:
> On 15/04/10 12:46 AM, Andy Walls wrote:
> > On Wed, 2010-04-14 at 18:26 -0400, Mark Lord wrote:
> .
>
> Mmmm.. but it does do read-modify-write on several registers inside the IRQ
> handling.
> I suppose those might be "safe" groups, written t
On 15/04/10 01:16 AM, Mark Lord wrote:
for now, I've added lower level spinlock protection onto all
register writes,
..
As you expected, this doesn't seem to have cured anything obvious. :)
I had Mythtv wakeup/record/powerdown several times overnight,
and it still required "fallbacks" for ab
On 15/04/10 12:46 AM, Andy Walls wrote:
On Wed, 2010-04-14 at 18:26 -0400, Mark Lord wrote:
..
Oddly, none of those spinlocks use _irq or _irq_save/restore,
which means they aren't providing any sort of mutual exclusion
against the interrupt handler.
There is no need. The hard irq handler on
On Wed, 2010-04-14 at 18:26 -0400, Mark Lord wrote:
> On 14/04/10 12:32 AM, Mark Lord wrote:
> ..
> > The syslog shows the usual "fallback" messages,
> > but the audio consisted of very loud static, the kind
> > of noise one gets when the sample bits are all reversed.
> >
> > While it was failing,
On 14/04/10 12:32 AM, Mark Lord wrote:
..
The syslog shows the usual "fallback" messages,
but the audio consisted of very loud static, the kind
of noise one gets when the sample bits are all reversed.
While it was failing, I tried retuning, stopping/starting
the recording, etc.. nothing mattered
On 14/04/10 12:32 AM, Mark Lord wrote:
..
Thanks. I'll have a go at that some night.
Meanwhile, tonight, audio failed.
..
Oh, I forgot to include this:
Apr 13 22:00:05 duke kernel: cx18-0: = START STATUS CARD #0
=
Apr 13 22:00:05 duke kernel: cx18-0: Version
On 13/04/10 09:45 PM, Andy Walls wrote:
..
# v4l2-dbg -d /dev/video0 -c host1 --list-registers=min=0x800,max=0x9ff
Keep in mind that some of these registers aren't settable and only read
out the state of various hardware blocks and functions.
Dumping the state of the microcontroller memory cou
On Tue, 2010-04-13 at 08:42 -0400, Mark Lord wrote:
> On 13/04/10 06:35 AM, Andy Walls wrote:
> > On Mon, 2010-04-12 at 22:34 -0400, Mark Lord wrote:
> ..
> >> As soon as I quit from LiveTV, the next recording still needed
> >> a new fallback. So the chip is still in some weird state where
> >> au
On 13/04/10 06:35 AM, Andy Walls wrote:
On Mon, 2010-04-12 at 22:34 -0400, Mark Lord wrote:
..
As soon as I quit from LiveTV, the next recording still needed
a new fallback. So the chip is still in some weird state where
auto-audio will continue to fail until I reload the module.
..
The *onl
On Mon, 2010-04-12 at 22:34 -0400, Mark Lord wrote:
> On 12/04/10 10:30 PM, Mark Lord wrote:
> ..
> > Mmm.. further to that: the problem went away as soon as I told
> > it to tune to a different channel. No more fallbacks (for now).
> > It can now even retune the original channel without fallbacks.
On 12/04/10 10:30 PM, Mark Lord wrote:
..
Mmm.. further to that: the problem went away as soon as I told
it to tune to a different channel. No more fallbacks (for now).
It can now even retune the original channel without fallbacks.
So.. tuning to a new channel appears to fix whatever the bad sta
On 12/04/10 10:22 PM, Mark Lord wrote:
..
Okay, the "fallback" works -- recordings made with it do have good audio.
And.. my hypothesis appears to be true thus far: once the audio fails,
requiring the fallback, it stays failed until the driver is reloaded.
Every subsequent recording made (after
On 12/04/10 05:17 PM, Andy Walls wrote:
On Mon, 2010-04-12 at 16:08 -0400, Mark Lord wrote:
..
I wonder if this means that once the audio bug is present,
it remains present until the next time the driver is loaded/unloaded.
Which matches previous observations.
The fallback (hopefully) works
On Mon, 2010-04-12 at 16:08 -0400, Mark Lord wrote:
> On 11/04/10 03:01 PM, Andy Walls wrote:
> >
> > I would be interested in hearing how frequent these patches show "forced
> > audio standard" for you:
> ..
>
> The MythTV box here has many tuners, most of which are not used every
> power-up.
>
On 11/04/10 03:01 PM, Andy Walls wrote:
I would be interested in hearing how frequent these patches show "forced
audio standard" for you:
..
The MythTV box here has many tuners, most of which are not used every power-up.
But mythbackend _always_ initializes all tuners, and pre-tunes them to th
On 11/04/10 03:01 PM, Andy Walls wrote:
..
I can always throw the other reset patches back in I guess, but this
latest patch set should dominate the behavior of the microcontroller (if
I didn't miss something because I was tired).
I would be interested in hearing how frequent these patches show
Andy Walls wrote:
On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote:
On 10/04/10 06:54 PM, Andy Walls wrote:
Hmmm. Darren's having problems (loss of video/black screen) with my
patches under my cx18-audio repo, but I'm not quite convinced he doesn't
have some other PCI bus problem eit
On Sun, 2010-04-11 at 09:24 -0400, Mark Lord wrote:
> On 11/04/10 07:47 AM, Andy Walls wrote:
> > On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote:
> >> Try this:
> >>
> >>http://linuxtv.org/hg/~awalls/cx18-audio2
> >>
> >> this waits 1.5 seconds after an input/channel change to see if the a
On 11/04/10 07:47 AM, Andy Walls wrote:
On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote:
Try this:
http://linuxtv.org/hg/~awalls/cx18-audio2
this waits 1.5 seconds after an input/channel change to see if the audio
standard micrcontroller can detect the standard. If it can't, the
d
On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote:
> On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote:
> > On 10/04/10 06:54 PM, Andy Walls wrote:
> > >
> > > Hmmm. Darren's having problems (loss of video/black screen) with my
> > > patches under my cx18-audio repo, but I'm not quite convinced
On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote:
> On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote:
> > On 10/04/10 06:54 PM, Andy Walls wrote:
> > >
> > > Hmmm. Darren's having problems (loss of video/black screen) with my
> > > patches under my cx18-audio repo, but I'm not quite convinced
On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote:
> On 10/04/10 06:54 PM, Andy Walls wrote:
> >
> > Hmmm. Darren's having problems (loss of video/black screen) with my
> > patches under my cx18-audio repo, but I'm not quite convinced he doesn't
> > have some other PCI bus problem either.
> >
> >
On 10/04/10 06:54 PM, Andy Walls wrote:
Hmmm. Darren's having problems (loss of video/black screen) with my
patches under my cx18-audio repo, but I'm not quite convinced he doesn't
have some other PCI bus problem either.
Anyway, my plan now is this:
1. on cx18-av-core.c:input_change()
On Sat, 2010-04-10 at 18:54 -0400, Andy Walls wrote:
> On Sat, 2010-04-10 at 18:28 -0400, Mark Lord wrote:
> > On 15/03/10 07:51 AM, Andy Walls wrote:
> > > On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
> > >> On 03/02/10 07:40, Andy Walls wrote:
> > ..
> > >> after updating to the tip of the
On Sat, 2010-04-10 at 18:28 -0400, Mark Lord wrote:
> On 15/03/10 07:51 AM, Andy Walls wrote:
> > On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
> >> On 03/02/10 07:40, Andy Walls wrote:
> ..
> >> after updating to the tip of the v4l2-dvb git tree last week,
> >> I've been hitting the "no audi
On 15/03/10 07:51 AM, Andy Walls wrote:
On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
On 03/02/10 07:40, Andy Walls wrote:
..
after updating to the tip of the v4l2-dvb git tree last week,
I've been hitting the "no audio" on analog recordings bug much more often.
Digging through google,
On Tue, 2010-03-16 at 00:49 -0400, Mark Lord wrote:
> On 03/15/10 07:51, Andy Walls wrote:
> > On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
> >> If the audio is not working after modprobe, then simply doing
> >> rmmod/modprobe
> >> in a loop (until working audio is achieved) is enough to c
On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
> On 03/02/10 07:40, Andy Walls wrote:
> > Again, maybe dynamically allocating these work order objects from the
> > kernel as needed, would be better from a small dynamically allocated
> > pool for each card. I was concerned that the interrupt h
On 03/02/10 07:40, Andy Walls wrote:
Again, maybe dynamically allocating these work order objects from the
kernel as needed, would be better from a small dynamically allocated
pool for each card. I was concerned that the interrupt handler was
taking to long at the time I implemented the things t
38 matches
Mail list logo
