Mailinglist Archive: radeonhd (363 mails)
| < Previous | Next > |
[radeonhd] [patch] Use MMIO macros for portability
- From: Michael Cree <mcree@xxxxxxxxxxxx>
- Date: Wed, 25 Mar 2009 09:57:52 +1300
- Message-id: <8B787731-49B1-4CBF-976C-37E00A02CF0A@xxxxxxxxxxxx>
I attach a patch to modify the _RHDRegRead() and _RHDRegWrite()
functions (and their debug versions) to use the MMIO macros provided
by the compiler.h header file.
These macros provide portable access to the memory mapped I/O registers of the graphics card. They take account of endian, alignment and cpu scheduling issues for the architectures supported by the xserver.
These patches resolve the mucked up colour issue I had reported for an HD2400 card on an Alpha ev56 CPU. The instruction scheduler of the CPU may totally remove writes to a memory address if there are subsequent writes to the same memory address with no intervening reads. That is a safe and valid strategy for normal memory access, but not when the memory address is an I/O port. The MMIO macros insert memory barriers for those architectures that need it.
I suspect this patch may resolve a number of reported issues where people have used the radeonhd driver on architectures other than x86.
I haven't done a full audit of the radeonhd code and so I wouldn't know for sure whether my patch covers every instance of direct memory access to the I/O ports. I do know that I haven't addressed AtomBIOS access. Since it is ROM memory barriers are not so important, but endian and alignment issues still need to be resolved in that code.
Cheers
Michael.
These macros provide portable access to the memory mapped I/O registers of the graphics card. They take account of endian, alignment and cpu scheduling issues for the architectures supported by the xserver.
These patches resolve the mucked up colour issue I had reported for an HD2400 card on an Alpha ev56 CPU. The instruction scheduler of the CPU may totally remove writes to a memory address if there are subsequent writes to the same memory address with no intervening reads. That is a safe and valid strategy for normal memory access, but not when the memory address is an I/O port. The MMIO macros insert memory barriers for those architectures that need it.
I suspect this patch may resolve a number of reported issues where people have used the radeonhd driver on architectures other than x86.
I haven't done a full audit of the radeonhd code and so I wouldn't know for sure whether my patch covers every instance of direct memory access to the I/O ports. I do know that I haven't addressed AtomBIOS access. Since it is ROM memory barriers are not so important, but endian and alignment issues still need to be resolved in that code.
Cheers
Michael.
| < Previous | Next > |