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

[Lauri Kasanen]

On Fri, 28 Feb 2014 16:43:54 +0100
Christian König <deathsimple at 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.

- Lauri