Bug#572311: No display output from Radeon RV610 on Alpha

Michael Cree mcree at orcon.net.nz
Sat Mar 13 00:57:26 PST 2010


On 13/03/10 06:57, Alex Deucher wrote:
> On Fri, Mar 12, 2010 at 4:57 AM, Michael Cree<mcree at orcon.net.nz>  wrote:
>> On 10/03/10 08:44, Alex Deucher wrote:
>>>>>>>
>>>>>>> On Sun, Mar 7, 2010 at 3:47 AM, Michael Cree<mcree at orcon.net.nz>
>>>>>>>   wrote:
>>>>>>>>
>>>>>>>> Thanks, that hint was helpful.  I have drummed up a patch (attached)
>>>>>>>> that
>>>>>>>> replaces some use of the UINT16LE_TO_CPU(), etc., macros with generic
>>>>>>>> interfaces from the Xserver's compiler.h header file.  Now works
>>>>>>>> correctly
>>>>>>>> on RV610 video card on an Alpha XP1000.  Have also verified that the
>>>>>>>> driver
>>>>>>>> still works on an RV710 card on AMD64 architecture.
>>>
>>> Can you add the alignment stuff to the ATOM_BSWAP16/32 functions in
>>> radeon_atombios.c?
>>> e.g.,
>>> return ldw_u(bswap_16(x));
>>
>> That's a good idea, however I think the ldw_u() must be inside the byte swap
>> as the (mis)alignment issues must be dealt with at the point of loading the
>> datum, whereas endianess can be fixed later.
>>
>> Attached is a new patch that uses the ldw_u() macros and also leaves the
>> UINT16LE_TO_CPU, etc., macros in place.  Verified working on Alpha and AMD64
>> architectures, but I don't have a suitable big-endian machine to test this.
>
> Wouldn't it be cleaner to just put the ldw_u() in ATOM_BSWAP16()?
>
> --- a/src/radeon_atombios.c
> +++ b/src/radeon_atombios.c
> @@ -28,6 +28,7 @@
>   #endif
>   #include "xf86.h"
>   #include "xf86_OSproc.h"
> +#include "compiler.h"
>
>   #include "radeon.h"
>   #include "radeon_reg.h"
> @@ -2981,7 +2982,7 @@
> atombios_get_command_table_version(atomBiosHandlePtr atomBIOS, int
> index, int *m
>
>   UINT16 ATOM_BSWAP16(UINT16 x)
>   {
> -    return bswap_16(x);
> +    return bswap_16(ldw_u(x));
>   }

No, that won't work for two reasons:

1) It's only in the big endian code path.  There are little endian 
architectures that need the ldw_u().

2) ldw_u()'s argument is a pointer (i.e. the address from which the word 
is to be loaded) not a value.  This is also the reason that I didn't 
include the ldw_u()s in the UINT16LE_TO_CPU, etc., macro definitions in 
Decoder.h.  Those macros sometimes wrap an access via a pointer and at 
other times they wrap an actual value.  Use of ldw_u() is only 
appropriate at the actual access of a datum from the AtomBios, i.e., 
those cases that perform an access through a pointer.

Cheers
Michael.





More information about the xorg-driver-ati mailing list