possible regression Radeon RV280 (R3xx/R4xx ?) card freeze, re-apply old patch ?

[Jochen Rollwagen]

I think there are two issues here: the first is the missing alignment 
workaround, since i'll be upgrading to 3.4.69 anyway i'll insert some 
diagnostic messages in radeon_device.c and see what happens. But i'm 
pretty certain now that this isn't the cause for the lockups. They are 
probably (quite certainly) caused by the dynamic binding/unbinding of 
AGP memory which the Uninorth chipset used in 32-bit powermacs obviously 
doesn't support. All it supports seems to be statically allocating a 256 
MB contigouous non-cacheable AGP aperture and using that (since the 
chipset doesn't do any address mapping via the GART as indicated in the 
OpenBSD code). So to get AGP mode working again on those machines one 
would have to disable the dynamic memory stuff. Question: Would that 
require changes in the driver only or also in the DRM ?

Cheers

Jochen

Am 14.11.2013 02:37, schrieb Michel Dänzer:
> On Mit, 2013-11-13 at 19:07 +0100, Jochen Rollwagen wrote:
>> I started investigating the problem because AGP mode used to work with
>> the UMS drivers (although I now understand they didn’t really use AGP
>> memory)
> They used AGP memory but didn't dynamically bind memory to the AGP
> aperture or unbind it from there.
>
>
>> and in the second patch I mentioned below Benjamin Herrenschmidt
>> stated that “there's a chip errata (for the pre-R600 chips). On those
>> chips, the aperture must be aligned to the aperture size (that is
>> FB_START in MC_FB_LOCATION must be aligned to the aperture size).”
>> Since that workaround/patch definitely isn’t in the current DRM code
>> any more (probably got lost in the transition to KMS) my idea was to
>> re-apply the three-line workaround/patch (which should be quite
>> trivial given the comment in radeon_vram_location in the drm kernel
>> code).
> So, have you verified that the aperture is not aligned to its size for
> you? If it's not, does aligning it help stability with AGP?
>
>