On Don, 2011-10-27 at 22:19 -0500, Ilija Hadzic wrote:
> On Thu, 27 Oct 2011, Daniel Vetter wrote:
>
> > So I think the right thing to do is
> > - Kill dev->last_vblank_wait (in a prep patch).
>
> Agreed. Also drm_vblank_info function can go away
Actually, I was rather going to submit a patch t
On Thu, 27 Oct 2011, Ilija Hadzic wrote:
>
>> While locking at the code I also noticed that wait_vblank calls
>> drm_vblank_get, but not always drm_vblank_put. The code is correct, the
>> missing vblank_put is hidden in drm_queue_vblank_event. Can you also write
>> the patch to move that around
On Thu, Oct 27, 2011 at 01:07:35PM +0200, Daniel Vetter wrote:
> Now that we are again in proper control of owner_list, we need to
> properly list_del it on free.
>
> Signed-off-by: Daniel Vetter
Chris Wilson rightly complained that this doesn't explain the list_del
magic going on. New commit ms
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #48 from Ilija Hadzic
2011-10-27 15:33:33 PDT ---
> first) and apply the patch as 'patch -p1 name_of_the_patch.patch'
Typo, it should be
patch -p1 < name_of_the_patch.patch
^
but you probably already know that
--
Co
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #47 from Ilija Hadzic
2011-10-27 15:31:31 PDT ---
(In reply to comment #45)
> mmm... I wanted to try it but I still don't understand how to apply it (what
> version of files, where to get them and what command to run). I'm used with
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #46 from Ilija Hadzic
2011-10-27 15:27:15 PDT ---
Created attachment 52833
--> https://bugs.freedesktop.org/attachment.cgi?id=52833
provisional patch to try as an experiment
--
Configure bugmail: https://bugs.freedesktop.org/user
On Thu, 27 Oct 2011, Daniel Vetter wrote:
>
> On a quick glance
> - drm_vblank functions call by wait_vblank seem to do correct locking
> already using various spinlocks and atomic ops.
> - linux waitqueues have their own locking
> - dev->last_vblank_wait is only used for a procfs file. I don't
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #45 from Siganderson 2011-10-27 15:05:52 PDT
---
mmm... I wanted to try it but I still don't understand how to apply it (what
version of files, where to get them and what command to run). I'm used with
patchfiles and patch -pNum < pa
On Thu, 27 Oct 2011, Ilija Hadzic wrote:
While locking at the code I also noticed that wait_vblank calls
drm_vblank_get, but not always drm_vblank_put. The code is correct, the
missing vblank_put is hidden in drm_queue_vblank_event. Can you also write
the patch to move that around to not tri
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #12 from Michal 2011-10-27 13:39:59 PDT
---
csm->gart_limit and csm->vram_limit are correct.
With GARTSize "64", openarena works great. ETRacer does not (but no fallbacks)
In ETRacer, when I disabled show fps in options, after few s
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #44 from Siganderson 2011-10-27 13:36:58 PDT
---
I'll try the patch.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
On Thu, 27 Oct 2011, Daniel Vetter wrote:
On a quick glance
- drm_vblank functions call by wait_vblank seem to do correct locking
already using various spinlocks and atomic ops.
- linux waitqueues have their own locking
- dev->last_vblank_wait is only used for a procfs file. I don't think it
Hi Linus,
this is the main pull request for the drm tree, I've got some more stuff
coming but it all looks like -fixes stuff so no reason to hold this up
which I had ready pre-ks except for some reverts off a radeon/ttm feature
that wasn't what we wanted yet.
Highlights:
Samsung: exynos SoC m
From: Alex Deucher
The vram scratch was originally only used on some 7xx asics
to work around a hw bug. Allocate the scratch page on all 6xx+
radeons and set the MC_VM_SYSTEM_APERTURE_DEFAULT_ADDR to point
to it. We shouldn't ever hit it since we limit the system
aperture to vram or vram and AG
2011/10/25 Christian K?nig :
> Better fix it before this obvious typo spreads even more.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
> ---
> ?drivers/gpu/drm/radeon/radeon.h ? ? ? | ? ?4 +-
> ?drivers/gpu/drm/radeon/radeon_fence.c | ? 34
> ?driv
2011/10/25 Christian K?nig :
> Having registered debugfs files globally causes
> the files to not show up on the second, third
> etc.. card in the system.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
> ---
> ?drivers/gpu/drm/radeon/radeon.h ? ? ? ?| ? ?8 +++
> ?drivers/gpu/d
https://bugs.freedesktop.org/show_bug.cgi?id=42090
Tom Stellard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
From: Alex Deucher
The vram scratch was originally only used on some 7xx asics
to work around a hw bug. Allocate the scratch page on all 6xx+
radeons and set the MC_VM_SYSTEM_APERTURE_DEFAULT_ADDR to point
to it. We shouldn't ever hit it since we limit the system
aperture to vram or vram and AG
I think page_flip ioctl need to realize a synchronous mechanism to control
fresh rate...!!!
At 2011-10-25 20:30:39,"Ben Skeggs" wrote:
>On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
>> Maarten Maathuis writes:
>>
>> > 2011/10/25 chris :
>> >> Can anyone give a suggestion, is wait-vb
2011/10/25 Christian König :
> Better fix it before this obvious typo spreads even more.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon.h | 4 +-
> drivers/gpu/drm/radeon/radeon_fence.c | 34
> driv
2011/10/25 Christian König :
> Having registered debugfs files globally causes
> the files to not show up on the second, third
> etc.. card in the system.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon.h | 8 +++
> drivers/gpu/d
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #48 from Ilija Hadzic 2011-10-27
15:33:33 PDT ---
> first) and apply the patch as 'patch -p1 name_of_the_patch.patch'
Typo, it should be
patch -p1 < name_of_the_patch.patch
^
but you probably already know that
--
Co
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #47 from Ilija Hadzic 2011-10-27
15:31:31 PDT ---
(In reply to comment #45)
> mmm... I wanted to try it but I still don't understand how to apply it (what
> version of files, where to get them and what command to run). I'm used with
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #46 from Ilija Hadzic 2011-10-27
15:27:15 PDT ---
Created attachment 52833
--> https://bugs.freedesktop.org/attachment.cgi?id=52833
provisional patch to try as an experiment
--
Configure bugmail: https://bugs.freedesktop.org/user
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #45 from Siganderson 2011-10-27 15:05:52 PDT ---
mmm... I wanted to try it but I still don't understand how to apply it (what
version of files, where to get them and what command to run). I'm used with
patchfiles and patch -pNum < pat
On Thu, Oct 27, 2011 at 01:07:35PM +0200, Daniel Vetter wrote:
> Now that we are again in proper control of owner_list, we need to
> properly list_del it on free.
>
> Signed-off-by: Daniel Vetter
Chris Wilson rightly complained that this doesn't explain the list_del
magic going on. New commit ms
On Thu, Oct 27, 2011 at 12:12:09PM -0400, Alex Deucher wrote:
> On Wed, Oct 26, 2011 at 11:41 AM, wrote:
> > From: Jerome Glisse
> >
> > Cayman seems to be particularly sensitive to read cache returning
> > old data after bind/unbind to GTT. Flush read cache for GTT range
> > with each fences fo
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #12 from Michal 2011-10-27 13:39:59 PDT ---
csm->gart_limit and csm->vram_limit are correct.
With GARTSize "64", openarena works great. ETRacer does not (but no fallbacks)
In ETRacer, when I disabled show fps in options, after few se
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #44 from Siganderson 2011-10-27 13:36:58 PDT ---
I'll try the patch.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
_
On 10/27/2011 12:49 PM, Francisco Jerez wrote:
> Thomas Hellstrom writes:
>
>
>> FWIW, there was a quite long discussion / argument when the page flip
>> ioctl was designed, and at that time
>> I pointed out that there are hardware capable of pageflipping using
>> the fifo/pipe with optional V
Noticed while killing code in the area ...
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_memory.c | 19 ---
include/drm/drmP.h |5 -
2 files changed, 0 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memor
We have debugfs and sysfs for these things now!
Digging through the dungeons of old code and wading through countless
result pages on google indeed turned up one user of this:
libdrm before 2001 checks via the presence of /proc/dri/0 whether
the kernel drm is present and has a module successfully
Signed-off-by: Daniel Vetter
---
include/drm/drm_pciids.h | 42 --
1 files changed, 0 insertions(+), 42 deletions(-)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 3d53efd..ecd09a3 100644
--- a/include/drm/drm_pciids.h
+++ b/inclu
With the last patch to ditch DMA_QUEUE support, we should be able
to call the dma cleanup uncoditionally, even when the master has
disappeared.
Do so because it just makes more sense.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c |6 +++---
1 files changed, 3 insertions(+), 3
Absolutely unused. All the values are only ever initialized and
then used at most in some debug printout functions.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 16 ++--
drivers/gpu/drm/drm_debugfs.c |1 -
drivers/gpu/drm/drm_dma.c |5 -
dr
Only one driver (i810) even sets that flag. Now the actual locking code
uncoditionally promotes lock->context to an unsigned int.
Closer inspection of the userspace reveals that the drm lock context
is defined as an unsigned int (at least on linux). I suspect
we just have a strange case of signedn
All leftover users either haven't set DRIVER_HAVE_DMA, in which
case this will never be called, or use the drm_core implementation.
Call that directly in the only callsite.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c|5 ++---
drivers/gpu/drm/i915/i915_drv.c
The reclaim_buffers function of the savage driver actually wants to run
with the hw_lock held - at least there are printks in the call-chain
to that effect. But the drm core only calls reclaim_buffers as used
by savage _after_ forcefully dropping the hwlock (in case it's still
hold by the closing f
i810 was the last user of this code, with that gone, kill it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c | 46 +--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |1 -
include/drm/drmP.h |2 -
3 files changed, 1 insertions
My dear old i815 always hits the deadlocked on reclaim_buffers
warning. Switch over to the idlelock duct-tape on hope that
works better. I've fired up my i815 and now closing glxgears doesn't
take 5 seconds anymore. \o/
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i810/i810_dma.c | 17
The only two users are now folded into the drivers preclose functions,
so this is unused.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c |8
include/drm/drmP.h |2 --
2 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c
Like for via.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/sis/sis_drv.c |3 +--
drivers/gpu/drm/sis/sis_mm.c | 12 ++--
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sis/sis_drv.c b/drivers/gpu/drm/sis/sis_drv.c
index 278d1b0..1b299cc 100644
A few things
- kill reclaim_buffers, it's never ever called because via does not set
DRIVER_HAVE_DMA
- inline the idlelock dance into the buffer reclaim logic and make it
a simple preclose cleanup function
- directly call the the dma_quiescent function and kill the needless
if check.
Export
No longer used.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/Makefile |2 +-
drivers/gpu/drm/drm_sman.c | 210
include/drm/drm_sman.h | 151 ---
3 files changed, 1 insertions(+), 362 deletions(-)
delete mod
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/sis/sis_drv.c |4 -
drivers/gpu/drm/sis/sis_drv.h |5 +-
drivers/gpu/drm/sis/sis_mm.c | 137 +++-
3 files changed, 68 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/sis/sis_drv.c b/drivers
Now that we are again in proper control of owner_list, we need to
properly list_del it on free.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/via/via_drv.h |5 ++-
drivers/gpu/drm/via/via_map.c |7
drivers/gpu/drm/via/via_mm.c | 72 ++--
3 f
No longer used.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_sman.c | 36 ++--
include/drm/drm_sman.h |5 -
2 files changed, 2 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/drm_sman.c b/drivers/gpu/drm/drm_sman.c
index 37a8844.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/sis/sis_drv.c |4 +++
drivers/gpu/drm/sis/sis_drv.h |2 +
drivers/gpu/drm/sis/sis_mm.c | 60 ++--
drivers/gpu/drm/via/via_map.c |2 +
4 files changed, 53 insertions(+), 15 deletions(-)
diff --git
Massive indirection through a hashtable for a simple key->pointer
look-up actually just adds bloat.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/via/via_drv.h |2 +
drivers/gpu/drm/via/via_map.c |1 +
drivers/gpu/drm/via/via_mm.c | 61 +++--
3 f
In contrast to kms drivers, sis/via _always_ associated a buffer with
a drm fd. So by the time we reach lastclose, all open drm fds are gone
and with them their associated objects.
So when sis/via call drm_sman_cleanup in their lastclose funcs, that
will free 0 objects.
The owner tracking now ser
These are now unused.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_sman.c | 38 --
include/drm/drm_sman.h | 19 ---
2 files changed, 0 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/drm_sman.c b/drivers/gpu/drm/drm
Exactly like the previous patch for sis.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/via/via_drv.c | 25 +
drivers/gpu/drm/via/via_mm.c | 22 ++
include/drm/via_drm.h |4
3 files changed, 43 insertions(+), 8 deletions(-)
dif
By attach a driver private struct to each open drm fd.
Because we steal the owner_list from drm_sman until things settle,
use list_move instead of list_add.
This requires to export a drm_sman function temporarily before
drm_sman will die for real completely.
Signed-off-by: Daniel Vetter
---
dr
Hi all,
It's that time of the year again when the weather gets crappy, people
depressed and danvet wades through drm cruft. Not that any of this is
related in any way.
Actually I only wanted to port users of drm_mm to the new interfaces,
completing a work I've started a while ago. It lead to a li
case where you have several channels trying to render to the
>>>> same pageflipped drawable, to make sure that the flips are properly
>>>> synchronized with respect each other.
>>>> ___
>>>> dri-devel mailing list
>>>> dri-devel at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111027/a627a592/attachment.pgp>
On Wed, Oct 26, 2011 at 05:33:24PM -0500, Ilija Hadzic wrote:
> Is DRM support for other OS-es officially dead ? I know it's not in
> best shape on BSD and friends, but I am not sure if I should make it
> worse (or inconsistent with the current code shape and form).
I think the idea of sharing ker
On Wed, Oct 26, 2011 at 11:41 AM, wrote:
> From: Jerome Glisse
>
> Cayman seems to be particularly sensitive to read cache returning
> old data after bind/unbind to GTT. Flush read cache for GTT range
> with each fences for all new hw. Should fix several rendering glitches.
> Like
>
> V2 flush w
Hi Linus,
this is the main pull request for the drm tree, I've got some more stuff
coming but it all looks like -fixes stuff so no reason to hold this up
which I had ready pre-ks except for some reverts off a radeon/ttm feature
that wasn't what we wanted yet.
Highlights:
Samsung: exynos SoC m
FWIW, there was a quite long discussion / argument when the page flip
ioctl was designed, and at that time
I pointed out that there are hardware capable of pageflipping using the
fifo/pipe with optional VSYNC barriers, and that it is actually possible
to queue up a number of pageflips in the fif
On Thu, Oct 27, 2011 at 12:12:09PM -0400, Alex Deucher wrote:
> On Wed, Oct 26, 2011 at 11:41 AM, wrote:
> > From: Jerome Glisse
> >
> > Cayman seems to be particularly sensitive to read cache returning
> > old data after bind/unbind to GTT. Flush read cache for GTT range
> > with each fences fo
On Thu, 27 Oct 2011, Alan Coopersmith wrote:
>>
>> I think the idea of sharing kernel drm code is pretty much dead, yeah.
>
> We are still trying to keep it alive, despite what some may think.
>
In the context of this patch (in progress), it's probably a moot topic
because per comments that D
On Wed, Oct 26, 2011 at 11:41 AM, wrote:
> From: Jerome Glisse
>
> Cayman seems to be particularly sensitive to read cache returning
> old data after bind/unbind to GTT. Flush read cache for GTT range
> with each fences for all new hw. Should fix several rendering glitches.
> Like
>
> V2 flush w
On Wed, 26 Oct 2011 14:40:07 +0900
Joonyoung Shim wrote:
> 10/25/2011 06:46 PM, Jesse Barnes 쓴 글:
>
> [snip]
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index 8020798..d7f03aa 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -44,6 +44,7 @@
be needed for hot plug.
--
Jesse Barnes, Intel Open Source Technology Center
------ next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111027/347bd6d2/attachment.pgp>
On Thu, 27 Oct 2011, Alan Coopersmith wrote:
I think the idea of sharing kernel drm code is pretty much dead, yeah.
We are still trying to keep it alive, despite what some may think.
In the context of this patch (in progress), it's probably a moot topic
because per comments that Daniel
On 10/27/11 03:43, Daniel Vetter wrote:
On Wed, Oct 26, 2011 at 05:33:24PM -0500, Ilija Hadzic wrote:
Is DRM support for other OS-es officially dead ? I know it's not in
best shape on BSD and friends, but I am not sure if I should make it
worse (or inconsistent with the current code shape and fo
On 10/27/11 03:43, Daniel Vetter wrote:
> On Wed, Oct 26, 2011 at 05:33:24PM -0500, Ilija Hadzic wrote:
>> Is DRM support for other OS-es officially dead ? I know it's not in
>> best shape on BSD and friends, but I am not sure if I should make it
>> worse (or inconsistent with the current code shap
On 10/27/2011 12:49 PM, Francisco Jerez wrote:
Thomas Hellstrom writes:
FWIW, there was a quite long discussion / argument when the page flip
ioctl was designed, and at that time
I pointed out that there are hardware capable of pageflipping using
the fifo/pipe with optional VSYNC barriers,
Noticed while killing code in the area ...
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_memory.c | 19 ---
include/drm/drmP.h |5 -
2 files changed, 0 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memor
We have debugfs and sysfs for these things now!
Digging through the dungeons of old code and wading through countless
result pages on google indeed turned up one user of this:
libdrm before 2001 checks via the presence of /proc/dri/0 whether
the kernel drm is present and has a module successfully
Signed-off-by: Daniel Vetter
---
include/drm/drm_pciids.h | 42 --
1 files changed, 0 insertions(+), 42 deletions(-)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 3d53efd..ecd09a3 100644
--- a/include/drm/drm_pciids.h
+++ b/inclu
With the last patch to ditch DMA_QUEUE support, we should be able
to call the dma cleanup uncoditionally, even when the master has
disappeared.
Do so because it just makes more sense.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c |6 +++---
1 files changed, 3 insertions(+), 3
Absolutely unused. All the values are only ever initialized and
then used at most in some debug printout functions.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 16 ++--
drivers/gpu/drm/drm_debugfs.c |1 -
drivers/gpu/drm/drm_dma.c |5 -
dr
Only one driver (i810) even sets that flag. Now the actual locking code
uncoditionally promotes lock->context to an unsigned int.
Closer inspection of the userspace reveals that the drm lock context
is defined as an unsigned int (at least on linux). I suspect
we just have a strange case of signedn
All leftover users either haven't set DRIVER_HAVE_DMA, in which
case this will never be called, or use the drm_core implementation.
Call that directly in the only callsite.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c|5 ++---
drivers/gpu/drm/i915/i915_drv.c
The reclaim_buffers function of the savage driver actually wants to run
with the hw_lock held - at least there are printks in the call-chain
to that effect. But the drm core only calls reclaim_buffers as used
by savage _after_ forcefully dropping the hwlock (in case it's still
hold by the closing f
i810 was the last user of this code, with that gone, kill it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c | 46 +--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |1 -
include/drm/drmP.h |2 -
3 files changed, 1 insertions
My dear old i815 always hits the deadlocked on reclaim_buffers
warning. Switch over to the idlelock duct-tape on hope that
works better. I've fired up my i815 and now closing glxgears doesn't
take 5 seconds anymore. \o/
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i810/i810_dma.c | 17
The only two users are now folded into the drivers preclose functions,
so this is unused.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c |8
include/drm/drmP.h |2 --
2 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c
Like for via.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/sis/sis_drv.c |3 +--
drivers/gpu/drm/sis/sis_mm.c | 12 ++--
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sis/sis_drv.c b/drivers/gpu/drm/sis/sis_drv.c
index 278d1b0..1b299cc 100644
A few things
- kill reclaim_buffers, it's never ever called because via does not set
DRIVER_HAVE_DMA
- inline the idlelock dance into the buffer reclaim logic and make it
a simple preclose cleanup function
- directly call the the dma_quiescent function and kill the needless
if check.
Export
No longer used.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/Makefile |2 +-
drivers/gpu/drm/drm_sman.c | 210
include/drm/drm_sman.h | 151 ---
3 files changed, 1 insertions(+), 362 deletions(-)
delete mod
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/sis/sis_drv.c |4 -
drivers/gpu/drm/sis/sis_drv.h |5 +-
drivers/gpu/drm/sis/sis_mm.c | 137 +++-
3 files changed, 68 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/sis/sis_drv.c b/drivers
Now that we are again in proper control of owner_list, we need to
properly list_del it on free.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/via/via_drv.h |5 ++-
drivers/gpu/drm/via/via_map.c |7
drivers/gpu/drm/via/via_mm.c | 72 ++--
3 f
No longer used.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_sman.c | 36 ++--
include/drm/drm_sman.h |5 -
2 files changed, 2 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/drm_sman.c b/drivers/gpu/drm/drm_sman.c
index 37a8844.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/sis/sis_drv.c |4 +++
drivers/gpu/drm/sis/sis_drv.h |2 +
drivers/gpu/drm/sis/sis_mm.c | 60 ++--
drivers/gpu/drm/via/via_map.c |2 +
4 files changed, 53 insertions(+), 15 deletions(-)
diff --git
Massive indirection through a hashtable for a simple key->pointer
look-up actually just adds bloat.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/via/via_drv.h |2 +
drivers/gpu/drm/via/via_map.c |1 +
drivers/gpu/drm/via/via_mm.c | 61 +++--
3 f
In contrast to kms drivers, sis/via _always_ associated a buffer with
a drm fd. So by the time we reach lastclose, all open drm fds are gone
and with them their associated objects.
So when sis/via call drm_sman_cleanup in their lastclose funcs, that
will free 0 objects.
The owner tracking now ser
These are now unused.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_sman.c | 38 --
include/drm/drm_sman.h | 19 ---
2 files changed, 0 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/drm_sman.c b/drivers/gpu/drm/drm
Exactly like the previous patch for sis.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/via/via_drv.c | 25 +
drivers/gpu/drm/via/via_mm.c | 22 ++
include/drm/via_drm.h |4
3 files changed, 43 insertions(+), 8 deletions(-)
dif
By attach a driver private struct to each open drm fd.
Because we steal the owner_list from drm_sman until things settle,
use list_move instead of list_add.
This requires to export a drm_sman function temporarily before
drm_sman will die for real completely.
Signed-off-by: Daniel Vetter
---
dr
Hi all,
It's that time of the year again when the weather gets crappy, people
depressed and danvet wades through drm cruft. Not that any of this is
related in any way.
Actually I only wanted to port users of drm_mm to the new interfaces,
completing a work I've started a while ago. It lead to a li
Thomas Hellstrom writes:
> FWIW, there was a quite long discussion / argument when the page flip
> ioctl was designed, and at that time
> I pointed out that there are hardware capable of pageflipping using
> the fifo/pipe with optional VSYNC barriers, and that it is actually
> possible to queue u
On Wed, Oct 26, 2011 at 05:33:24PM -0500, Ilija Hadzic wrote:
> Is DRM support for other OS-es officially dead ? I know it's not in
> best shape on BSD and friends, but I am not sure if I should make it
> worse (or inconsistent with the current code shape and form).
I think the idea of sharing ker
FWIW, there was a quite long discussion / argument when the page flip
ioctl was designed, and at that time
I pointed out that there are hardware capable of pageflipping using the
fifo/pipe with optional VSYNC barriers, and that it is actually possible
to queue up a number of pageflips in the fif
I think page_flip ioctl need to realize a synchronous mechanism to control
fresh rate...!!!
At 2011-10-25 20:30:39,"Ben Skeggs" wrote:
>On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
>> Maarten Maathuis writes:
>>
>> > 2011/10/25 chris :
>> >> Can anyone give a suggestion, is wait-vb
https://bugs.freedesktop.org/show_bug.cgi?id=42297
Bug #: 42297
Summary: [r600g] Segfaults and failed assertions with piglit
test fbo-generatemipmap-formats
Classification: Unclassified
Product: Mesa
Version: git
Platf
97 matches
Mail list logo
