[PATCH] drm/radeon: Always flush VM again on < CIK

[Marek Olšák]

So what's difference between WRITE_DATA with PFP vs ME? Would it also
be preferable for DMA_DATA and COPY_DATA?

Marek

On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
> On Thu, Aug 7, 2014 at 3:46 AM, Michel Dänzer <michel at daenzer.net> wrote:
>> From: Michel Dänzer <michel.daenzer at amd.com>
>>
>> Not doing this causes piglit hangs[0] on my Cape Verde card. No issues on
>> Bonaire and Kaveri though.
>>
>> [0] Same symptoms as those fixed on CIK by 'drm/radeon: set VM base addr
>> using the PFP v2'.
>>
>> Signed-off-by: Michel Dänzer <michel.daenzer at amd.com>
>
> We should be using PFP as much as possible.  Does the attached patch help?
>
> Alex
>
>> ---
>>  drivers/gpu/drm/radeon/radeon_vm.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c b/drivers/gpu/drm/radeon/radeon_vm.c
>> index ccae4d9..898cbb7 100644
>> --- a/drivers/gpu/drm/radeon/radeon_vm.c
>> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
>> @@ -238,7 +238,9 @@ void radeon_vm_flush(struct radeon_device *rdev,
>>         uint64_t pd_addr = radeon_bo_gpu_offset(vm->page_directory);
>>
>>         /* if we can't remember our last VM flush then flush now! */
>> -       if (!vm->last_flush || pd_addr != vm->pd_gpu_addr) {
>> +       /* XXX figure out why we have to flush all the time before CIK */
>> +       if (rdev->family < CHIP_BONAIRE ||
>> +           !vm->last_flush || pd_addr != vm->pd_gpu_addr) {
>>                 trace_radeon_vm_flush(pd_addr, ring, vm->id);
>>                 vm->pd_gpu_addr = pd_addr;
>>                 radeon_ring_vm_flush(rdev, ring, vm);
>> --
>> 2.0.1
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>