Does drm/dri currently work on PPC?

[matt]

On 10/26/12 05:15, Justin Hibbits wrote:
> On Fri, Oct 26, 2012 at 12:55 AM, matt <sendtomatt at gmail.com
> <mailto:sendtomatt at gmail.com>> 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 openbsd.org <mailto:mpi at openbsd.org>, Justin & Nathan!
>
>     Matt
>
>
> That's fantastic!  If I'm able to get my current project done (PMU
> sleep/speed change on PowerBook) I'll definitely give that a shot this
> weekend.
>
> One thing that may help with switching back to syscons is, NetBSD has
> a radeonfb driver for console framebuffer.Earlier in the week I
> briefly looked at that, and it may not be too difficult to port it to
> FreeBSD and integrate with syscons.  Only major hurdle for that would
> be dealing with ofwfb as well.  Just some more tinkering :)
>
> Excellent news!
>
> - Justin
New development, I get random hangs...I'm going to try disabling EXA for
XAA. Backtrace during hang:

#0  0x41fd4b28 in ioctl () from /lib/libc.so.7
#1  0x420c0a7c in drmIoctl () from /usr/local/lib/libdrm.so.2
#2  0x420c0bdc in drmCommandNone () from /usr/local/lib/libdrm.so.2
#3  0x421a03e8 in RADEONWaitForIdleCP ()
   from /usr/local/lib/xorg/modules/drivers/radeon_drv.so
#4  0x421feef8 in RADEONSyncCP ()
   from /usr/local/lib/xorg/modules/drivers/radeon_drv.so
#5  0x42295748 in exaWaitSync () from /usr/local/lib/xorg/modules/libexa.so
#6  0x42296d40 in ExaDoPrepareAccess ()
   from /usr/local/lib/xorg/modules/libexa.so
#7  0x42297e90 in exaPrepareAccessReg_classic ()
   from /usr/local/lib/xorg/modules/libexa.so
#8  0x42296f14 in exaPrepareAccess ()
   from /usr/local/lib/xorg/modules/libexa.so
#9  0x422a2c78 in ExaCheckImageGlyphBlt ()
   from /usr/local/lib/xorg/modules/libexa.so
#10 0x01976a6c in miImageText8 ()
#11 0x018f2f0c in DamageSetup ()
#12 0x018337ec in doImageText ()
#13 0x01833984 in ImageText ()
#14 0x0182cb48 in ProcImageText8 ()
#15 0x0182efe8 in Dispatch ()
#16 0x01823188 in main ()

Is this 8bit DRM crashing it because unlike 16 and 32 it's not byteswapped?
BTW, mesa-demos compiles if you insert a copy of byteswap.h (I got mine
from arnold.se's article about bitcoin, of all things) and you define
the powerpc write barrier.

Matt