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@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
