[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openvortex-dev] Findings...

From: Manuel Jander
Subject: Re: [Openvortex-dev] Findings...
Date: Tue, 22 Apr 2003 22:50:22 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4

Hi Jeff,

Other than that, it would probably be a better idea to initialize the
Vortex hardware *before* attempting to grab the IRQ using
request_irq(...), since then the card would be properly initialized
and ready to handle IRQs properly at that point. It would probably
stop the spurious IRQ_TIMER from happening as well when grabbing the

Yes, this appears to be a good idea and is what the binary driver appears
to do. I have made a fix and committed it to cvs.


from vortex_core_init:

 // vortex_enable_int() must be first !!

        what does this apply to?
I discovered that when i enable first an interrupt source mask bit in VORTEX_IRQ_CTRL (for example the PCM out IRQ source bit) and after that the global interrupt enable bit my computer hangs (hard lock). In the reverse order, no problem. No idea why.

 hwwrite(vortex->mmio, VORTEX_IRQ_CTRL, 0);

        where is this from?

This is supposed to reset all IRQ source bits. So If the global interrupt bit is set,
no interrupt should be generated, except if one interrupt is pending.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]