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 at 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 at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
