Related to this question, one thing that I noticed is that in some instances, I would not see any interrupts at all. Instead, all signaled fences would be taken care of next time somebody waits on one them (through radeon_fence_wait, radeon_fence_signaled, radeon_fence_poll_locked call sequence -- the last function has the loop that marks all fences signaled that should be).

Is that also expected behavior ?

-- Ilija

On Mon, 12 Sep 2011, Alex Deucher wrote:

On Sat, Sep 10, 2011 at 12:35 PM, Vipin vj358@nyu.edu wrote:

...

Hello,

First, my system set up

Fedora 14 Before : 2.6.35.6 booted with drm.debug=0x07

I see drm:r600_irq_process, IH: CP int: 0x00000000 and No IH: CP EOP

with the default fedora 14 install with the above mentioned kernel

After: 3.0.3 booted with drm.debug=0x07 When I recompile my kernel, I don't see any CP int: , but only CP EOP interrupts.

I have seen this behaviour across two machines one with fedora install & another with an ubuntu 10.10 (2.6.35.28 -> 3.0.3)

The code in r600.c specified plain switch based on the received case. Does this mean the case 176-178 are not executed when I recompile the kernel ? which doesn't sound right because its being shown in the previous kernel ?

Am I doing any mistake ? Any missing option in kernel configuration ? but then I shouldn't even see CP EOP.

Firmware exists in /lib/firmware/radeon

Any further pointers are appreciated. Please ask for more information.

The CP interrupt and the CP EOP interrupt are different interrupts. The driver uses them for the same purpose. Older kernels use the CP int and newer kernels use the CP EOP interrupt as that is the preferred method of operation for what we are using it for (GPU fences).

Alex _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel