Date: Thu, 25 Oct 2012 19:38:17 -0700 From: matt <sendtomatt@gmail.com> To: Justin Hibbits <chmeeedalf@gmail.com> Cc: freebsd-x11@freebsd.org, Albert Vest <alvest@brakiri.com>, freebsd-ppc@freebsd.org Subject: Re: Does drm/dri currently work on PPC? Message-ID: <5089F799.9030507@gmail.com> In-Reply-To: <20121025213018.2bfa5068@narn.knownspace> References: <5083C719.1040109@gmail.com> <CAKLtBChswXj7HcZeC=SaJgMNDrZXu==DHFP5PW4wB9=ruKSWWA@mail.gmail.com> <20121021092136.20307802@narn.knownspace> <50846392.70007@gmail.com> <CAHSQbTC7SA8qiVGQi%2BfmsmzYBVQLR09Dmzhjk1Ev=srsufc_HQ@mail.gmail.com> <5085F595.4050609@gmail.com> <20121022215945.436873dc@narn.knownspace> <5089A6DB.9070904@brakiri.com> <5089DF27.9020803@gmail.com> <20121025213018.2bfa5068@narn.knownspace>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/25/12 18:30, Justin Hibbits wrote: > On Thu, 25 Oct 2012 17:53:59 -0700 > matt <sendtomatt@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, >>> Albert. >>> >> 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 @ >> 0x????????/65536 >> [ 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. Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5089F799.9030507>