Does drm/dri currently work on PPC? (SUCCESS!)

Andreas Tobler andreast-list at
Sat Oct 27 17:14:07 UTC 2012

On 27.10.12 03:11, matt wrote:
> On 10/26/12 11:51, Andreas Tobler wrote:
>> On 26.10.12 16:31, Nathan Whitehorn wrote:
>>> On 10/25/12 23:55, matt wrote:
>>>>> It was working without DRM "out-of-the-box". Of course I've made a
>>>>> mess
>>>>> trying different versions of both Xorg and the radeon driver. I'm
>>>>> in the
>>>>> process of getting back to the working config so I can be sure any
>>>>> test
>>>>> changes work/don't work.
>>>>> OpenBSD's mpi@ apparently did a lot recently over there getting DRM to
>>>>> work on the G4 mini. We already had about half of the commits I see at
>>>>> freshbsd, in one way or another...Our rmb/wmb() I think has had PPC
>>>>> barriers since earlier this year? He did #define __BIG_ENDIAN, which
>>>>> apparently was a big deal for the drm code (it's ifdef'd in a couple
>>>>> places), not sure if we are already doing that.
>>>>> If someone has a G4 radeon mini they could test to see if drm works
>>>>> for
>>>>> them or not, to rule out AGP issues (I guess they are PCI?).
>>>>> I'm not sure how the OpenBSD attachment process works vs ours, some of
>>>>> the other commits of note were related to passing the BAR and memory
>>>>> regions from the vgapci to drm. When I kldload drm after compiling it,
>>>>> it doesn't do anything...but if I kldload radeon.ko, it recognizes agp
>>>>> memory and being related to vgapci at the correct pci address...I'm
>>>>> not
>>>>> sure if we "are there" or not. I also didn't have DRM on OpenBSD
>>>>> either.
>>>>> I think if radeon had drm on *any* big-endian platform it should rule
>>>>> out endian issues in drm or radeon. Not sure if this is the case, I
>>>>> guess macppc would be the most likely.
>>>>> Matt
>>>> So I removed WITH_NEW_XORG, deinstalled a ton of ports, and reinstalled
>>>> Xorg. I rebuild drm with __BIG_ENDIAN defined (not sure if this
>>>> matters). I previously put a lot of WERROR= and NO_WERROR= into various
>>>> drm makefiles to get gcc to shut up about unused return values. X
>>>> -configure worked, and the xorg log indicates the drm device was
>>>> successfully opened and I have drm on PPC.
>>>> mesa-demos is marked broken for PPC, haven't tried glxinfo or
>>>> glxgears yet.
>>>> The good news is it works!
>>>> The bad news:
>>>> -Cannot switch back to syscons, screen gets corrupted then the system
>>>> hard locks
>>>> -WITH_NEW_XORG breaks it somehow
>>>> Thanks to mpi at, Justin & Nathan!
>>>> Matt
>>>> _______________________________________________
>>>> freebsd-ppc at mailing list
>>>> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe at"
>>> Great to hear! I checked in some code to define __BIG_ENDIAN if needed
>>> in -CURRENT's drm (Linux uses a different number of underscores than we
>>> do for perverse reasons).
>> Thank you very much all!
>> I can confirm it works here too (G5 32-bit):
>> [helium:~] andreast% dmesg |grep drm
>> drm0: <ATI Radeon AR 9600 XT> on vgapci0
>> info: [drm] Initialized radeon 1.31.0 20080613
>> info: [drm] Setting GART location based on new memory map
>> info: [drm] Loading R300 Microcode
>> info: [drm] Num pipes: 1
>> info: [drm] writeback test succeeded in 1 usecs
>> and glxgears gives around 1250FPS vs. 52FPS w/o dri.
>> Andreas
> Can you change consoles or exit X successfully?
> btw...issue "sync" a couple times first just in case :)
> Also, is that an AGP or PCIe G5?

I can exit X and restart X successfully. I can also switch 
(ctrl-alt-F1-F8) between X and console and back (ctrl-alt-F9). Even with 
glxgears running. No lock-up.

It is an AGP card:
(--) RADEON(0): Chipset: "ATI Radeon 9600XT AR (AGP)" (ChipID = 0x4152)
(--) RADEON(0): Mapped VideoRAM: 131072 kByte (128 bit DDR SDRAM)

These are my modules:
Section "Module"
         Load  "extmod"
         Load  "record"
         Load  "dbe"
         Load  "glx"
         Load  "dri"
         Load  "dri2"

And nothing special in the driver section.


More information about the freebsd-x11 mailing list