Tech Insider					   Technology and Trends


			   USENET Archives

List:       linux-video
Subject:    [video4linux] Long standing bttv bug
From:       alan () lxorguk ! ukuu ! org ! uk (Alan Cox)
Date:       1998-08-29 1:54:24

I've been hunting this one for a while. There is a long standing bttv
problem with some cirrus cards and acceleration and another about
mode switches. In both cases the bttv stops capturing video but is
otherwise ok.

I finally pinned it down

Both are PCI stopping the DMA engine. IRQ_SCERR is asserted. The driver
recovery code fails to work at this point. Until the module is reloaded
capture will not continue. All other functions work fine.

Alan


------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.

List:       linux-video
Subject:    Re: [video4linux] Long standing bttv bug
From:       alexb () jetsuite ! com (Bakaev, Alex)
Date:       1998-08-29 1:30:24

If I remember correctly, Cirrus guys ( and S3 too ) had to implement
some swich in their display driver under Windows so we could turn it on
and off when 848 was capturing ( has to do with how they handle PCI bus
). I'll see if that info can be released somehow.

Alex

Alan Cox wrote:
> 
> I've been hunting this one for a while. There is a long standing bttv
> problem with some cirrus cards and acceleration and another about
> mode switches. In both cases the bttv stops capturing video but is
> otherwise ok.
> 
> I finally pinned it down
> 
> Both are PCI stopping the DMA engine. IRQ_SCERR is asserted. The driver
> recovery code fails to work at this point. Until the module is reloaded
> capture will not continue. All other functions work fine.
> 
> Alan
> 
> ------------
> To unsubscribe from this list send mail to majordomo@phunk.org with the
> line "unsubscribe video4linux" without the quotes in the body of the
> message.
------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.

List:       linux-video
Subject:    Re: [video4linux] Long standing bttv bug
From:       alan () lxorguk ! ukuu ! org ! uk (Alan Cox)
Date:       1998-08-29 2:31:42

> If I remember correctly, Cirrus guys ( and S3 too ) had to implement
> some swich in their display driver under Windows so we could turn it on
> and off when 848 was capturing ( has to do with how they handle PCI bus
> ). I'll see if that info can be released somehow.

S3 seems to be fine, as do the later Cirrus. The problem that needs fixing
isnt so much the SCERR as the fact the bttv driver isnt recovering from it.
Losing a frame now and then to a bitblt is fine. Having to reload the driver
is less cool.

For the Cirrus you can tell the Xserver not to use acceleration, and sent
the memory fifos down to leave more bandwidth (tho at 1024x768 on the 
5430 you lose anyway looking at the docs)

Alan

------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.

List:       linux-video
Subject:    [video4linux] BTTV bugs part 2
From:       Alan Cox <alan () cymru ! net>
Date:       1998-08-30 17:33:26

I finally had time to play with a bttv setup on a non Linux box and did
a bit more testing. We've got another extremely obvious bug at least on
the PAL Hauppauge.

Under Lose95 the video is tracking subtle frequency shifts, under Linux
they cause the device to lose sync and often video capture until you detune
and retune it.

The easy way to demo this is to warm up a bttv card while watching TV .
Once you do it under both OS's its very obvious the Linux driver has bad
problems with something in the tuning.

Alan
------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.

List:       linux-video
Subject:    Re: [video4linux] BTTV bugs part 2
From:       "Michael H. Warfield" <mhw () wittsend ! com>
Date:       1998-08-30 18:42:43

Alan Cox enscribed thusly:
> I finally had time to play with a bttv setup on a non Linux box and did
> a bit more testing. We've got another extremely obvious bug at least on
> the PAL Hauppauge.

> Under Lose95 the video is tracking subtle frequency shifts, under Linux
> they cause the device to lose sync and often video capture until you detune
> and retune it.

> The easy way to demo this is to warm up a bttv card while watching TV .
> Once you do it under both OS's its very obvious the Linux driver has bad
> problems with something in the tuning.

	Warming up?  Hmmm...  Is this implying that the Hauppauge is
performing some sort of AFC which the bttv driver is failing to enable or
is the Lose95 driver tracking some sort of PLL error and trimming the
frequency setting periodically?  The difference could be significant.

	When you say "subtle frequency shifts", I assume that you are
referring to subtle frequency shifts in the tuner which is probably
originating in thermal drift in the tuner PLL reference oscillator.
That would cause the frequency to drift even though the PLL divisors
remained the same.  An AFC might apply a corrective bias to the PLL or
the frequency reference directly.  Manual correction would be to note the
PLL error and adjust the divisors to comphensate.

	Side note:  I'm not using the Hauppage board, but I find the
problem interesting.  My setup is an STB board on an NTSC cable system.
That has been pretty stable to date...

> Alan

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (770) 925-8248   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!
------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.

List:       linux-video
Subject:    Re: [video4linux] BTTV bugs part 2
From:       Alan Cox <alan () cymru ! net>
Date:       1998-08-30 20:00:19

> 	Warming up?  Hmmm...  Is this implying that the Hauppauge is
> performing some sort of AFC which the bttv driver is failing to enable or
> is the Lose95 driver tracking some sort of PLL error and trimming the
> frequency setting periodically?  The difference could be significant.

Not sure. 

> 	When you say "subtle frequency shifts", I assume that you are
> referring to subtle frequency shifts in the tuner which is probably
> originating in thermal drift in the tuner PLL reference oscillator.
> That would cause the frequency to drift even though the PLL divisors
> remained the same.  An AFC might apply a corrective bias to the PLL or
> the frequency reference directly.  Manual correction would be to note the
> PLL error and adjust the divisors to comphensate.

The actual behaviour I see in these circumstances is that the picture
latches when you hit the channel but then slips off channel, or at least
the video sync is lost. Retuning down and back up recovers it - its like the
AFC is only being applied while the tune in occurs not afterwards

On Lose95 the picture is held reliably

------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.

			   USENET Archives


The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or 
research.


Electronic mail:			      WorldWideWeb:
   tech-insider@outlook.com		         http://tech-insider.org/