Re: eee + glx

["Blair Sadewitz" <blair.sadewitz%gmail.com@localhost>]

>> On 8/29/08, Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
>>  >  modload drm
>>  >  modload i915drm
>>  >
FYI:

Currently, the i915 module is vastly more reliable than the
radeon module.  If it works for you, I'm glad to hear it; however,
in any case where there're untoward issues, please try
building the code into the kernel as usual, as they're not
bug-free yet (at least insofar as I'm aware).

Additionally, if anyone's using a radeon card with our drm,
please do try this patch:

<http://www.netbsd.org/~bjs/drm-latest.diff>

This patch includes a bunch of improvements I've accumulated
over time, including:

- Uses cv(9) instead of mtsleep.
- Uses pool_cache(9) memory allocator in radeon_mem.c
  (if you have issues with this, please let me know, but it
  seems to work for me, at least).
- Uses bus_dma(9) where appropriate instead of malloc(9),
  which should absolutely not be used e.g. for scatter/gather
  (also eliminates ugly vtophys() use in drm_vm.c).
- Uses "quick-n-dirty" mmap "cookies" for offsets passed
  to drm_mmap.  If you have a radeon card, this should
 allow you to use the drm on amd64.  Unfortunately,
 due to bugs in our revision of the i915 driver, this will
 break Intel cards (if you're interested in helping resolve this
issue, please contact me).  Once we have the newer drm code
 in src/sys/external working, this should no longer be an issue.
- Uses in-kernel realloc(9) instead of the drm-provided one.
- The interrupt handler and corresponding "drm_irq" mutex
  now use IPL_SOFTNET; IPL_VM was probably excessive.
- Various locking fixes in drm_bufs.c and drm_auth.c.
- The code allocating memory with bus_dma now keeps state
  information and provides verbose debugging output each time
  a mapping is removed.
- The mtrr functions in drm_memory.c now use the 'n'
  argument as intended.  That is, instead of this:

 return mtrr_set(&mtrrmap, &one, NULL, MTRR_GETSET_KERNEL);

where one is initialized to 1, they do this:

       KERNEL_LOCK(1, NULL);
       ret = mtrr_set(&mtrrmap, &n, NULL, MTRR_GETSET_KERNEL);
       if (n != 0) {
               mtrr_commit();
       }
       KERNEL_UNLOCK_ONE(NULL);
       return ret;

 If you're curious about this, see the code in e.g. i686_mem.c.
 Should I be mistaken in my use of our mtrr API, please
 do let me know!

Comments/suggestions/gripes/etc are always welcome
(so are volunteers!).

Regards,

--Blair