Re: [PATCH] drm/radeon: TTM must be init with cpu-visible VRAM

["Christian König" <deathsimple@vodafone.de>]

Am 28.02.2014 17:52, schrieb Lauri Kasanen:
> On Fri, 28 Feb 2014 16:43:54 +0100
> Christian König <deathsimple@vodafone.de> wrote:
>
>>>>> Am 27.02.2014 22:38, schrieb Lauri Kasanen:
>>>>>> Without this, a bo may get created in the cpu-inaccessible vram.
>>>>>> Before the CP engines get setup, all copies are done via cpu memcpy.
>>>>>>
>>>>>> This means that the cpu tries to read from inaccessible memory, fails,
>>>>>> and the radeon module proceeds to disable acceleration.
>>>>>>
>>>>>> Doing this has no downsides, as the real VRAM size gets set as soon as the
>>>>>> CP engines get init.
>>>>>>
>>>>>> This is a candidate for 3.14 fixes.
>>>>> This should be unnecessary, since TTM gets initialized only seeing the
>>>>> visible VRAM and later on radeon_ttm_set_active_vram_size gets called to
>>>>> increase the limit.
>>>>>
>>>>> If this isn't the case any more we should figure out why instead of
>>>>> working around it like this.
>>>> Negative, TTM gets initialized with real_vram just a few lines above
>>>> this patch, not visible_vram.
>>> git blame shows 7a50f01a from 2009, "drm/radeon/kms: vram sizing on
>>> certain r100 chips needs workaround." by Dave Airlie.
>>>
>>> So the TTM VRAM init has been wrong for five years, and only worked by
>>> accident because until now all allocations were done bottom-up.
>> Yeah, just came to the same conclusion. We probably never hit the case
>> in the last five years because we don't really access the memory before
>> we start the copy ring.
>>
>> Please fix ttm_bo_init_mm to use rdev->mc.visible_vram_size instead.
>>
>> That allocations are made bottom-up is relied upon in a couple of other
>> cases as well, the stolen VGA memory and the UVD firmware handling for
>> example.
> I initially did that, but it caused some issues. I didn't investigage
> it further, but I guess it has to be init to the maximum size, and then
> only the size lowered, so that the change only affects lpfn.

Fair enough, probably something gets allocated on init or something like 
that.

Please document that with a comment and resend the patch.

Christian.

>
> - Lauri