Does drm/dri currently work on PPC?
sendtomatt at gmail.com
Fri Oct 26 02:38:39 UTC 2012
On 10/25/12 18:30, Justin Hibbits wrote:
> On Thu, 25 Oct 2012 17:53:59 -0700
> matt <sendtomatt at gmail.com> wrote:
>> On 10/25/12 13:53, Albert Vest wrote:
>>> I also use Radeon r200, but on an i386 machine. Same symptom
>>> happens to me if I don't force BusType to PCI in my xorg.conf:
>>> Option "BusType" "PCI" # Force IGP to PCI
>>> hope that helps,
>> So far it doesn't look like that helps. It took a bit longer to crash,
>> and the screen flashed a pleasing pinkish-maroon before the system
>> locked up. I'm going to keep trying to fiddle driver section values,
>> but I think there's something architecturally wrong/missing.
>> Here's what I've noticed:
>> In /usr/src/sys/dev/drmP.h,
>> we have htole16 and htole32 wrapped around drm read and write
>> functions, which neither netbsd nor openbsd have (perhaps they wrap
>> it elsewhere). drm_read8 and drm_write8 on freebsd are not wrapped,
>> which seems odd to me? I can understand all or none, but "some" seems
>> like 8-bit reads and writes are either going to be the only ones that
>> work or the only ones that don't.
>> When I try to start X, I am also seeing this mess (X -configure as
>> well) with WITH_NEW_XORG. I have hw.ofwfb.relax_mmap=1.
>> [ 251.670] (WW) xf86EnableIO -1
>> [ 251.671] (II) xf86EnableIO: ffffffff
>> [ 251.671] (WW) Can't map IO space!
>> [ 251.671] (--) PCI: (0:0:16:0) 1002:4966:1002:4966 rev 1, Mem @
>> 0x98000000/134217728, 0x90000000/65536, I/O @ 0x00000400/256, BIOS @
>> [ 251.719] List of video drivers:
>> [ 251.719] ati
>> [ 251.719] radeon
>> [ 251.720] (II) LoadModule: "ati"
>> [ 251.791] (II)
>> Loading /usr/local/lib/xorg/modules/drivers/ati_drv.so [ 251.803]
>> (II) Module ati: vendor="X.Org Foundation" [ 251.803] compiled
>> for 1.10.6, module version = 6.14.6 [ 251.803] Module class:
>> X.Org Video Driver [ 251.803] ABI class: X.Org Video Driver,
>> version 10.0 [ 251.803] (II) LoadModule: "radeon"
>> [ 251.805] (II)
>> Loading /usr/local/lib/xorg/modules/drivers/radeon_drv.so
>> [ 251.895] (II) Module radeon: vendor="X.Org
>> Foundation" [ 251.895] compiled for 1.10.6, module version =
>> 6.14.6 [ 251.895] Module class: X.Org Video Driver
>> [ 251.895] ABI class: X.Org Video Driver, version 10.0
>> [ 251.895] (WW) xf86EnableIO -1 [ 251.895] (II) xf86EnableIO:
>> ffffffff [ 251.895] (WW) Can't map IO space!
>> [ 251.895] No devices to configure. Configuration failed.
> Can't help you with the X error issue you're seeing (does it work if
> you don't load the radeon module? That'd be the first thing to get
> working, then worry about drm), but you may be on to something with the
> DRM endian you found. NetBSD's drmP.h writes bus-order (little endian)
> only in register space, not in framebuffer space. Although I think this
> would only mess up the colors, but I may be wrong.
> Nice find!
> - Justin
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.
More information about the freebsd-x11