Stefan Lucke a écrit :
> On Montag 09 Oktober 2006 10:26, Nicolas Huillard wrote:
> 
>>Mark Adams a écrit :
>>
>>>>First : I still have field parity problems with interlaced material on
>>>>interlaced TV.
>>>
>>>Always, sometimes, coming and going, or just the odd glitch?
>>
>>"Coming and going".
>>Defined as : "On the same stream, parity can be OK for a few seconds up
>>to the minute, and then goes wrong, for a similar period. Pausing the
>>stream can get it right again. Or not."
> 
> That looks more like some interrupts are lost.
> Is VGA IRQ shared with other devices (/proc/interrupts) ?

Please excuse me for this late answer. I didn't check that post on the
DFB ML.

IRQ 11 is shared with USB (not used) and eth (heavily used, but not when
I watch TV....):
  11:   23638023          XT-PIC  uhci_hcd:usb1, viafb, eth0

Answer to Mark : it's not a multiprocessor system ("SMP alternatives:
switching to UP code"; "Freeing SMP alternatives: 0k freed")

When modprobing viafb, it report the following IRQ (dmesg):
 viafb: irq handler installed, IRQ(0x200) = 80080c02

I actually see those high IRQ numbers on other hosts, when the APIC is
enabled:
 185:   30244076   IO-APIC-level  eth0

On the EPIA VDR host, dmesg says :
 No local APIC present or hardware disabled
 mapped APIC to ffffd000 (011c1000)
Should it be that I have partly working IRQ routing. My kernel is
self-compiled 2.6.17 (from Debian source package).

> The other driver mentioned here:
> http://mail.directfb.org/pipermail/directfb-users/2006-September/002189.html
> 
> is using spin_locks() during interrupt processing :
> 
> +     spin_lock(&par->irq_lock);
> +     status = VIA_GET_MMIO(VIA_REG_INTERRUPT);
> +     if (status & VIA_IRQ_VBI_PENDING) {
> +             VIA_SET_MMIO(VIA_REG_INTERRUPT, status | VIA_IRQ_VBI_PENDING);
> +             wake_up_interruptible(&par->irq_queue);
> +             par->irq_count++;
> +             handled = 1;
> +     } else {
> +             handled = 0;
> +     }
> +     spin_unlock(&par->irq_lock);
> 
> In both cases I do not understand the logic in
> a. testing a bit
> b. writing back value with tested bit set

-- 
NH

_______________________________________________
directfb-users mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users

Reply via email to