Project

General

Profile

Actions

Bug #1721

closed

Patch: Port of FreeBSD Current drm, tested for r600 on x86_64

Added by davshao almost 14 years ago. Updated about 12 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

FreeBSD Current's sys/dev/drm, graphics drivers inside the kernel, has
been mostly ported to DragonFly with the exception of a partial
implementation (returns first integer available but no option to
specify a floor) of Linux's idr (small integer ID management) API and
with the exception of the entire via driver stack. A diff of the
entire port, which is 100k because several new files have been
imported virtually unchanged from FreeBSD, can be found at:

http://leaf.dragonflybsd.org/~davshao/r600fbsd.diff

A git branch r600fbsd can be found at

git://leaf.dragonflybsd.org/~davshao/dragonfly.git

Due to the hard work of others previously translating the equivalents
of locking (in some sense the port can be viewed as the limits of
porting without a full implementation of Linux's idr API), not much
more was done other than making obvious replacements.

A private hashtable implementation was imported from FreeBSD's
kern/subr_hash.c and sys/hash.h because of the lack of a hashdestroy()
function in the DragonFly equivalent APIs.

The port has been tested only on a Radeon HD 4550 on an x86_64 Shuttle
SG45H7. In particular I cannot guarantee that the port will work at
all on Intel graphics, although a few changes were made in the i915
code to add one new header file.

The major update appears to be in the Radeon section of the code. In
particular there are tests in one file radeon_state.c that appear for
the special case of Radeons r600 or later to skip certain IRQ
processing. Previous to the port I had succeeded in building the
latest git versions of X.org including libdrm and Mesa which enabled
me to load the hardware module in AIGLX, only the machine would lock
up hard. After the port, indications are that the proper hardware
modules are being loaded. For example, dmesg gives in part:

info: [drm] Initialized radeon 1.31.0 20080613
info: [drm] Setting GART location based on new memory map
info: [drm] Loading RV710 Microcode
info: [drm] Resetting GPU
info: [drm] writeback test succeeded in 1 usecs

while the corresponding Xorg.0.log log file has

95.404] drmOpenDevice: node name is /dev/dri/card0
[ 95.405] drmOpenDevice: open result is 11, (OK)
[ 95.405] drmOpenByBusid: Searching for BusID pci:0000:01:00.0
[ 95.405] drmOpenDevice: node name is /dev/dri/card0
[ 95.405] drmOpenDevice: open result is 11, (OK)
[ 95.405] drmOpenByBusid: drmOpenMinor returns 11
[ 95.405] drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
[ 95.507] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[ 95.507] (II) AIGLX: enabled GLX_SGI_make_current_read
[ 95.507] (II) AIGLX: enabled GLX_texture_from_pixmap with driver support
[ 95.507] (II) AIGLX: Loaded and initialized /opt/xtest/lib/dri/r600_dri.so
[ 95.507] (II) GLX: Initialized DRI GL provider for screen 0

Note the loading of r600_dri.so. It is very easy if anything goes
wrong for Mesa to simply fall back on the software driver, and on a
relatively fast machine it may not be easy to tell if running ordinary
applications. With the port one can run various Mesa demos under
mesa/mesa/progs/xdemos and watch for example the wheels go round.

Actions #1

Updated by tuxillo almost 14 years ago

Hi David,

I can succesfully start X with my Intel 945. I haven't done any intensive
testing yet though:

pciconf -lv output

vgapci1@pci0:0:2:1: class=0x038000 card=0x015b1025 chip=0x27a68086
rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = 'Mobile 945GM/GU Express Integrated Graphics Controller'
class = display

Below you can find the Xorg.0.log messages about DRM:

drmOpenByBusid: drmOpenMinor returns 10
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
(II) [drm] loaded kernel module for "i915" driver.
(II) [drm] DRM interface version 1.2
(II) [drm] DRM open master succeeded.
(II) intel(0): [drm] Using the DRM lock SAREA also for drawables.
(II) intel(0): [drm] framebuffer mapped by ddx driver
(II) intel(0): [drm] added 1 reserved context for kernel
(II) intel(0): X context handle = 0x1
(II) intel(0): [drm] installed DRM signal handler

Cheers,
Antonio Huete

Actions #2

Updated by davshao almost 14 years ago

Sorry for the late reply.

You don't know how relieved I am. :-) Fortunately the Intel code
basically was untouched, adding a couple of includes in the files.

David

On Fri, Apr 9, 2010 at 2:49 PM, Antonio Huete Jimenez (via DragonFly
issue tracker) <> wrote:

Antonio Huete Jimenez <> added the comment:

Hi David,

I can succesfully start X with my Intel 945. I haven't done any intensive
testing yet though:

pciconf -lv output

vgapci1@pci0:0:2:1:     class=0x038000 card=0x015b1025 chip=0x27a68086
rev=0x03 hdr=0x00
   vendor     = 'Intel Corporation'
   device     = 'Mobile 945GM/GU Express Integrated Graphics Controller'
   class      = display

Below you can find the Xorg.0.log messages about DRM:

drmOpenByBusid: drmOpenMinor returns 10
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
(II) [drm] loaded kernel module for "i915" driver.
(II) [drm] DRM interface version 1.2
(II) [drm] DRM open master succeeded.
(II) intel(0): [drm] Using the DRM lock SAREA also for drawables.
(II) intel(0): [drm] framebuffer mapped by ddx driver
(II) intel(0): [drm] added 1 reserved context for kernel
(II) intel(0): X context handle = 0x1
(II) intel(0): [drm] installed DRM signal handler

Cheers,
Antonio Huete

----------
status: unread -> chatting

_____________________________________________
DragonFly issue tracker <>
<http://bugs.dragonflybsd.org/issue1721>
_____________________________________________

Actions #3

Updated by swildner about 12 years ago

  • Description updated (diff)
  • Status changed from New to Closed
  • Assignee deleted (0)

Committed in 3f6063cc01b519b28ab36c05951d44c32dbf6a51

Thanks, David!

Actions

Also available in: Atom PDF