kernel recompile only drm r600_irq_process IH: CP EOP no CP int
ihadzic at research.bell-labs.com
Mon Sep 12 06:57:23 PDT 2011
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 ?
On Mon, 12 Sep 2011, Alex Deucher wrote:
> On Sat, Sep 10, 2011 at 12:35 PM, Vipin <vj358 at nyu.edu> wrote:
>> First, my system set up
>> Fedora 14
>> Before : 126.96.36.199 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
>> I have seen this behaviour across two machines one with fedora install &
>> another with an ubuntu 10.10 (188.8.131.52 -> 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
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
More information about the dri-devel