[Bug 13233] Build broken on FreeBSD

http://bugs.freedesktop.org/show_bug.cgi?id=13233 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug 13296] counters should be initialized at load time

http://bugs.freedesktop.org/show_bug.cgi?id=13296 --- Comment #2 from [EMAIL PROTECTED] 2007-11-18 22:38 PST --- Since most of the module gets reset between lastclose and firstopen, it makes sense to me that the counters would as well. Setting up the list of counters at load time wou

[Bug 13296] counters should be initialized at load time

http://bugs.freedesktop.org/show_bug.cgi?id=13296 --- Comment #1 from [EMAIL PROTECTED] 2007-11-18 20:55 PST --- Created an attachment (id=12621) --> (http://bugs.freedesktop.org/attachment.cgi?id=12621&action=view) Init counters at load time -- Configure bugmail: http://bugs.free

[Bug 13296] New: counters should be initialized at load time

http://bugs.freedesktop.org/show_bug.cgi?id=13296 Summary: counters should be initialized at load time Product: DRI Version: DRI CVS Platform: All OS/Version: FreeBSD Status: NEW Severity: normal Priority: medium

Re: dev->counter

On Sun, 2007-11-18 at 22:47 -0500, Robert Noland wrote: > Looking at this more, dev-counter is also incorrect with i915. In > i915_driver_load, we have dev->counter += 4, but in drm_firstopen we > initialize it to 6. > > I'm guessing that we should probably move that initialization to > drm_load

dev->counter

Looking at this more, dev-counter is also incorrect with i915. In i915_driver_load, we have dev->counter += 4, but in drm_firstopen we initialize it to 6. I'm guessing that we should probably move that initialization to drm_load... robert. -- Robert Noland <[EMAIL PROTECTED]> 2Hip Networks s

Re: patch to add _DRM_DRIVER flag

On Sun, 2007-11-18 at 18:24 -0500, Robert Noland wrote: > As discussed on irc... patch to add _DRM_DRIVER map flag so that > drm_lastclose won't clean up maps that the driver wants to manage. bah, missing (), corrected patch... robert. -- Robert Noland <[EMAIL PROTECTED]> 2Hip Networks 0001-A

[Bug 13233] Build broken on FreeBSD

http://bugs.freedesktop.org/show_bug.cgi?id=13233 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #12526|0 |1 is obsolete|

[Bug 13234] bus_space functions were imported in 3.0

http://bugs.freedesktop.org/show_bug.cgi?id=13234 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|dri-|[EMAIL PROTECTED] |

patch to add _DRM_DRIVER flag

As discussed on irc... patch to add _DRM_DRIVER map flag so that drm_lastclose won't clean up maps that the driver wants to manage. robert. -- Robert Noland <[EMAIL PROTECTED]> 2Hip Networks 0001-Add-_DRM_DRIVER-map-flag.patch Description: application/mbox signature.asc Description: This is a

Re: cleaning unfenced buffer

Jerome Glisse wrote: >Hi, > >If my driver emit fence function fail should there be a way >to clean unfenced buffer ? Or should i do this by myself in >the function which validate buffer ? If so then i915 execbuffer >is likely buggy in this regards (don't try to unload module >then as it will trigg

radeon syncronization

Hi, So while playing with buffer move i am facing a problem and would like to know if anyone ever faced it. I emitting a bitblt multi to move data from ttm to vram just after the bitblt multi there is a WAIT_UNTIL packet emitted with WAIT_2D_IDLECLEAN, WAIT_HOST_IDLECLEAN set however if i add a bl

irq_enabled

Hi, dev->irq_enabled is set to 0 in drm_setup (drm_fdops.c) is this really necessary ? Or would be ok i move this 0 things to drm functions which initialize drm structure and let then the flags be set by irq function. My problem is that i enable irq in load function so client don't have to worry a

cleaning unfenced buffer

Hi, If my driver emit fence function fail should there be a way to clean unfenced buffer ? Or should i do this by myself in the function which validate buffer ? If so then i915 execbuffer is likely buggy in this regards (don't try to unload module then as it will trigger BUG_ON(!list_empty(&bm->un