Harry Orenstein wrote:
On Sunday 28 August 2005 12:56 pm, Hans Verkuil wrote:
On Sunday 28 August 2005 17:49, Harry Orenstein wrote:
3) Captured the following from my kernel log (the only entries after
loading ivtv once I did "ivtvctl -D 64"):
Aug 28 11:32:38 gallifrey kernel: ivtv irq: ======= valid IRQ bits:
0x00000400 ======
Aug 28 11:33:09 gallifrey last message repeated 2013 times
Aug 28 11:34:10 gallifrey last message repeated 3985 times
Ah! This is the cause:
ivtv: Autodetected WinTV PVR 250 card (iTVC15 based)
iTVC15 is used for the PVR350 but apparently you also have one.
The interrupt that is active is the IVTV_IRQ_DEC_VSYNC interrupt, which
should only arrive on a PVR350 (with a decoder chip).
Also odd is this:
tveeprom: Hauppauge: model = 48012, rev = G310, serial# = 2600478
tveeprom: tuner = Philips FI1236 MK2 (idx = 10, type = 2)
tveeprom: tuner fmt = NTSC(M) (eeprom = 0x08, v4l2 = 0x00001000)
tveeprom: audio processor = MSP3445 (type = c)
tveeprom: decoder processor = Type 0x00 (type = 0)
The decoder processor (unrelated to the mpeg decoder on a PVR350) is 0.
What chip is on your board? AFAIK it should be an SAA7115.
Can you edit ivtv-driver.c: search for IVTV_IRQ_DEC_VSYNC and remove it
from the mask. Now try again and let me know if the problem is fixed.
Chances are that you still get interrupts in, but the errors should
hopefully be gone.
Hans
BRILLIANT!!
That worked!! Eliminates the ERR interrupts altogether as well as the ivtv
interrupts prior to starting a capture. When I start a capture, only the
ivtv interrupts increase, which is as it should be.
The change I made in ivtv-driver.c was to revert the check from "if
(ivtv->has_itvc15)" to "if ((itv->card->type == IVTV_CARD_PVR_350))". Can I
submit a patch for 0.3 and 0.2 branches to correct this, or is this a
solution too specific to my problem (i.e.: would it cause problems for other
card types)?
This is a great solution :), I can see how that was most likely the
better variable to follow even though technically we were adjusting to
the chip type it is really practically only a 350 anyway that will ever
actually decode too (although when using an itvc15 for encoding, it uses
the decoder firmware for some stuff like audio, even on a 250 without
decoding functionality, so that's why the firmware has to still load for
both dec/enc on those).
Thanks,
Chris
As far as the chip is concerned - I have an SAA7115. The driver doesn't seem
to have any problem loading the driver for it when I just do a "modprobe
ivtv".
Thanks again for all your help. If there is any other info you need please
let me know. This was really bugging me for a long time and I'm glad I
finally decided to pursue it.
-- Harry O.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
ivtv-devel mailing list
ivtv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
--
===
Chris Kennedy
[EMAIL PROTECTED]
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
ivtv-devel mailing list
ivtv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
