On 30.04.2012 17:45, Jerome Glisse wrote:
On Mon, Apr 30, 2012 at 10:50 AM, Christian König
wrote:
With that in place clients are automatically blocking
until their memory request can be handled.
v2: block only if the memory request can't be satisfied
in the first try, the first version a
On 30.04.2012 17:58, Jerome Glisse wrote:
On Mon, Apr 30, 2012 at 10:50 AM, Christian König
wrote:
Make the suballocator self containing to locking.
v2: split the bugfix into a seperate patch.
Signed-off-by: Christian König
I would say NAK but i don't have better solution yet to the issue.
On 2012-04-30 11:07 +0200, Maarten Maathuis wrote:
> On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> wrote:
> > On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
> >> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
> >> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler
> >> > wrote:
>
From: Alan Cox
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/oaktrail_device.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 4c5a186..d0b2244 100644
--- a/drivers/gpu/drm/
From: Alan Cox
If we set a small text framebuffer and have a bigger scanout then we want
to send black not random bits for the overscan.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/framebuffer.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/g
From: Alan Cox
Basically a straight cut/paste from the reference driver code then
cleaned up a spot.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_device.c | 115 ---
1 files changed, 52 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/gma
From: Alan Cox
Add the opregion support and bring us in line with the opregion functionality
in the
reference driver code. We can't share this with i915 currently because there are
hardcoded assumptions about dev_priv etc in both versions.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/M
2012/4/30 Christian König :
> Hi Dave,
>
> if nobody has a last moment concern please include the following patches in
> drm-next.
>
> Except for some minor fixes they have already been on the list for quite some
> time,
> but I intentional left out the debugfs related patches cause we haven't
>
On 30.04.2012 18:26, Jerome Glisse wrote:
On Mon, Apr 30, 2012 at 11:37 AM, Christian König
wrote:
On 30.04.2012 17:12, Jerome Glisse wrote:
On Mon, Apr 30, 2012 at 11:12 AM, Jerome Glisse
wrote:
On Mon, Apr 30, 2012 at 10:50 AM, Christian König
wrote:
Hi Dave,
if nobody has a last m
2012/4/30 Rafał Miłecki :
> This is one more patchset bringing minor improvements to the current
> HDMI implementation. I think after this step I'll start working on
> moving Evergreen HDMI code to the separated file. Some cleanups and
> making ACR re-usable were needed before that.
>
> Patches dep
> OK, this time bisecting started off relatively smoothly (doing the same
> "backwards" bisect on the branch-o-reverts as last time), but then my
> disk died halfway through... So I'll post the partial bisection results
> now (11 commits left to test), but I clearly have other things to fix
> befo
On Tue, May 1, 2012 at 8:22 AM, Christian König wrote:
> On 30.04.2012 17:45, Jerome Glisse wrote:
>>
>> On Mon, Apr 30, 2012 at 10:50 AM, Christian König
>> wrote:
>>>
>>> With that in place clients are automatically blocking
>>> until their memory request can be handled.
>>>
>>> v2: block only
On 2012-05-01 16:09 +0100, Alan Cox wrote:
> > OK, this time bisecting started off relatively smoothly (doing the same
> > "backwards" bisect on the branch-o-reverts as last time), but then my
> > disk died halfway through... So I'll post the partial bisection results
> > now (11 commits left to t
On Tue, 1 May 2012 11:31:23 -0400
Nick Bowler wrote:
> On 2012-05-01 16:09 +0100, Alan Cox wrote:
> > > OK, this time bisecting started off relatively smoothly (doing the same
> > > "backwards" bisect on the branch-o-reverts as last time), but then my
> > > disk died halfway through... So I'll p
From: Rob Clark
Previously these functions would assume that vma->vm_file was the
drm_file. Although if in some cases if the drm driver needs to use
something else for the backing file (such as the tmpfs filp) then this
assumption is no longer true. But vma->vm_private_data is still the
GEM obj
From: Dave Airlie
These can all be trigged from userspace if you pass the right values.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5e81
On Tue, May 1, 2012 at 12:39 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> These can all be trigged from userspace if you pass the right values.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_crtc.c | 10 +-
> 1 files changed, 5 insertions(+),
So it's pretty much the same patchset except for patch 7 (use mutex
instead of spinlock) and 9 & 10 which correspond to previous patch 9
split in two and the sa allocation being simplified.
The patchset can be found at :
http://people.freedesktop.org/~glisse/reset/
Cheers,
Jerome Glisse
___
From: Christian König
Different rings have different criteria to test
if they are stuck.
v2: rebased on current drm-next
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_asi
From: Christian König
It makes no sense at all to have more than one flag.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r100.c |1 -
drivers/gpu/drm/radeon/r300.c |1 -
drivers/gpu/drm/radeon/radeon.h
From: Christian König
Just register the debugfs files on init instead of
checking the chipset type multiple times.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_ring.c | 31 +++
1 files chan
From: Christian König
Removing all the different error messages and
having just one standard behaviour over all
chipset generations.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |7 ++-
drivers/gpu/drm/ra
From: Christian König
Previusly multiple rings could trigger multiple GPU
resets at the same time.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |3 +-
drivers/gpu/drm/radeon/radeon_fence.c | 150 +
2 f
From: Christian König
Aligning offset can make it bigger than tmp->offset
leading to an overrun bug in the following subtraction.
v2: Against initial suspicions this can't happen in mainline,
so no need to push it into stable.
Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
Revi
From: Christian König
Make the suballocator self containing to locking.
v2: split the bugfix into a seperate patch.
v3: Jerome Glisse use mutex, no reason to use spinlock that
are more heavyweight than mutex
Signed-off-by: Christian König
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/
From: Christian König
Dumping the current allocations.
v2: convert to mutex
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_object.h |5 +
drivers/gpu/drm/radeon/radeon_ring.c | 22 ++
drivers/gpu/drm/radeon/radeon_s
From: Jerome Glisse
The sa allocator is suppose to be a ring allocator, ie allocation
happen first at the end and if there is no more room we start at
the begining again. This patch make the code match this design.
sa_manager keep track of the start & end hole, it first try to
allocate in the end
From: Jerome Glisse
wakequeue is use in case we want to wait until we got something
that allow to allocate the object.
Signed-off-by: Christian König
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_gart.c |2 +-
drivers/gpu
From: Christian König
Instead of hacking the calculation multiple times.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_gart.c |6 ++
drivers/gpu/drm/radeon/radeon_object.h | 11 +++
drivers/gpu/drm/radeon/radeon_ring.c |6
From: Christian König
Directly use the suballocator to get small chunks
of memory. It's equally fast and doesn't crash when
we encounter a GPU reset.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c|1 -
drivers/gpu/drm/radeon/ni.c
From: Christian König
We should signal the caller that we haven't waited at all.
v2: only change fence_wait_next not fence_wait_last.
Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 files changed, 1
From: Christian König
As discussed with Michel that name better
describes the behavior of this function.
Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h|2 +-
drivers/gpu/drm/radeon/radeon_device.c |2 +-
From: Christian König
Should be used to free resource that are protected by a fence.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |8 -
drivers/gpu/drm/radeon/radeon_fence.c | 50 +---
2 files changed
From: Christian König
It's never used and so practically superfluous.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |1 -
drivers/gpu/drm/radeon/radeon_fence.c |7 ---
2 files changed, 0 insertions(+), 8 deletions(-)
diff --gi
From: Christian König
To prevent deadlocks under extreme conditions.
v2: rebase on top of new sa_manager patch
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_gart.c |2 +-
drivers/gpu/drm/rade
From: Christian König
It isn't necessary any more and the suballocator
seems to perform even better.
v2: ignore ERESTARTSYS in error reporting,
split fence changes into seperate patch,
use try_free SA callback to avoid lockups
v3: rebase on top of sa manager new patch
Signed-off-by: Chr
From: Christian König
Rings need to lock in order, otherwise
the ring subsystem can deadlock.
v2: fix error handling and number of locked doublewords.
v3: stop creating unneeded semaphores.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h
From: Christian König
Instead of all this humpy pumpy with recursive
mutex (which also fixes only halve of the problem)
move the actual gpu reset out of the fence code,
return -EDEADLK and then reset the gpu in the
calling ioctl function.
v2: Split removal of radeon_mutex into separate patch.
From: Christian König
Not needed anymore.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h| 44 +---
drivers/gpu/drm/radeon/radeon_cs.c | 10 +++---
drivers/gpu/drm/radeon/radeon_device.c |2 +-
drive
From: Christian König
It isn't chipset specific, so it makes no sense
to have that inside r100.c.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |5 +--
drivers/gpu/drm/radeon/ni.c |5 +--
drivers/gpu/drm/radeon/r100.c
From: Christian König
Don't hard code the 10 seconds timeout. Compute jobs
can run much longer.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeon/radeon_drv.c |4
drivers/gpu/drm/radeon/radeon_ring.c |
From: Christian König
Fixing just another deadlock problem with gpu reset tests.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_ring.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b
From: Christian König
Nothing chipset or ring specific with it,
so also move it to radon_ring.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c | 10 +-
drivers/gpu/drm/radeon/ni.c | 11 +--
drivers/gpu/drm/radeon/
From: Christian König
Since it is now identical to r100_gpu_is_lockup.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r300.c| 14 --
drivers/gpu/drm/radeon/radeon_asic.c | 16
drivers/gpu/drm/radeon/radeon_asic.h |
From: Christian König
Since it is now identical to evergreen_gpu_is_lockup.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/ni.c | 19 ---
drivers/gpu/drm/radeon/radeon_asic.c | 12 ++--
drivers/gpu/drm/radeon/radeon_as
https://bugs.freedesktop.org/show_bug.cgi?id=26891
--- Comment #21 from headwall 2012-05-01 10:24:20 PDT ---
I'm on a Mac Pro 1,1 with the original ATI X1900XT card, and had similar
problems booting via EFI. After the modesetting was initialized the screen went
blank, but the computer completed b
On Tue, May 1, 2012 at 1:19 PM, wrote:
> So it's pretty much the same patchset except for patch 7 (use mutex
> instead of spinlock) and 9 & 10 which correspond to previous patch 9
> split in two and the sa allocation being simplified.
>
> The patchset can be found at :
> http://people.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=49321
--- Comment #1 from Erno Kuusela 2012-05-01 11:46:08 PDT ---
Typo there in Mesa version, meant 8.0.2.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the as
https://bugs.freedesktop.org/show_bug.cgi?id=49321
Erno Kuusela changed:
What|Removed |Added
Platform|Other |x86-64 (AMD64)
Version|unspeci
On Sat, 28 Apr 2012 23:20:42 +0200
Patrik Jakobsson wrote:
> Signed-off-by: Patrik Jakobsson
Acked-by: Alan Cox
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
(re-adding Ben to the Cc because he was apparently dropped somewhere in
this thread)
On 2012-05-01 09:23 -0400, Nick Bowler wrote:
> On 2012-04-30 11:07 +0200, Maarten Maathuis wrote:
> > On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> > wrote:
> > > On Sat, Apr 28, 2012 at 11:33:50AM -0400,
Ok so i reread stuff and the :
drm/radeon: add general purpose fence signaled callback
is a big NAK actually. It change the paradigm. Moving most of
the handling into the irq process which is something i am intimatly
convinced we should avoid.
Here is the patchset up to ib pool cleanup. I have yet
From: Christian König
Different rings have different criteria to test
if they are stuck.
v2: rebased on current drm-next
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_asi
From: Christian König
It makes no sense at all to have more than one flag.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r100.c |1 -
drivers/gpu/drm/radeon/r300.c |1 -
drivers/gpu/drm/radeon/radeon.h
From: Christian König
Just register the debugfs files on init instead of
checking the chipset type multiple times.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_ring.c | 31 +++
1 files chan
From: Christian König
Removing all the different error messages and
having just one standard behaviour over all
chipset generations.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |7 ++-
drivers/gpu/drm/ra
From: Christian König
Previusly multiple rings could trigger multiple GPU
resets at the same time.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |3 +-
drivers/gpu/drm/radeon/radeon_fence.c | 150 +
2 f
From: Christian König
Aligning offset can make it bigger than tmp->offset
leading to an overrun bug in the following subtraction.
v2: Against initial suspicions this can't happen in mainline,
so no need to push it into stable.
Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
Revi
From: Christian König
Make the suballocator self containing to locking.
v2: split the bugfix into a seperate patch.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_sa.c | 17 +++--
2 files
From: Christian König
Dumping the current allocations.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_object.h |5 +
drivers/gpu/drm/radeon/radeon_ring.c | 22 ++
drivers/gpu/drm/radeon/radeon_sa.c | 14 +++
From: Jerome Glisse
The sa allocator is suppose to be a ring allocator, ie allocation
happen first at the end and if there is no more room we start at
the begining again. This patch make the code match this design.
sa_manager keep track of the start & end hole, it first try to
allocate in the end
From: Christian König
We should signal the caller that we haven't waited at all.
v2: only change fence_wait_next not fence_wait_last.
Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 files changed, 1
From: Christian König
As discussed with Michel that name better
describes the behavior of this function.
Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h|2 +-
drivers/gpu/drm/radeon/radeon_device.c |2 +-
From: Christian König
It's never used and so practically superfluous.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |1 -
drivers/gpu/drm/radeon/radeon_fence.c |7 ---
2 files changed, 0 insertions(+), 8 deletions(-)
diff --gi
From: Jerome Glisse
This allow to associate a fence with sa bo and retry and
wait if sa bo alloc can block.
v2: bug fixes
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h | 10 ++-
drivers/gpu/drm/radeon/radeon_cs.c|4 +-
drivers/gpu/drm/radeon/radeon_g
On Wed, May 2, 2012 at 12:00 AM, wrote:
> Ok so i reread stuff and the :
> drm/radeon: add general purpose fence signaled callback
> is a big NAK actually. It change the paradigm. Moving most of
> the handling into the irq process which is something i am intimatly
> convinced we should avoid.
>
>
Match the correct information which is DMI_PRODUCT_NAME instead of
DMI_BOARD_NAME
See dmidecode information on launchpad for both thin client:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911920
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911916
Thanks
Signed-off-by: Marc Garie
https://bugs.freedesktop.org/show_bug.cgi?id=49321
Bug #: 49321
Summary: Khronos WebGL conformance test and shadertoy failure
Classification: Unclassified
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: All
https://bugs.freedesktop.org/show_bug.cgi?id=49322
Bug #: 49322
Summary: No picture on display connected via Displayport
adaptor to HD 7870
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: x86-64 (
On 30.04.2012 17:58, Jerome Glisse wrote:
> On Mon, Apr 30, 2012 at 10:50 AM, Christian K?nig
> wrote:
>> Make the suballocator self containing to locking.
>>
>> v2: split the bugfix into a seperate patch.
>>
>> Signed-off-by: Christian K?nig
> I would say NAK but i don't have better solution yet
On 2012-04-30 11:07 +0200, Maarten Maathuis wrote:
> On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> wrote:
> > On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
> >> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
> >> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler >> > elliptictec
From: Alan Cox
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/oaktrail_device.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 4c5a186..d0b2244 100644
--- a/drivers/gpu/drm/
From: Alan Cox
If we set a small text framebuffer and have a bigger scanout then we want
to send black not random bits for the overscan.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/framebuffer.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/g
From: Alan Cox
Basically a straight cut/paste from the reference driver code then
cleaned up a spot.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_device.c | 115 ---
1 files changed, 52 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/gma
From: Alan Cox
Add the opregion support and bring us in line with the opregion functionality
in the
reference driver code. We can't share this with i915 currently because there are
hardcoded assumptions about dev_priv etc in both versions.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/M
2012/4/30 Christian K?nig :
> Hi Dave,
>
> if nobody has a last moment concern please include the following patches in
> drm-next.
>
> Except for some minor fixes they have already been on the list for quite some
> time,
> but I intentional left out the debugfs related patches cause we haven't
>
On 30.04.2012 18:26, Jerome Glisse wrote:
> On Mon, Apr 30, 2012 at 11:37 AM, Christian K?nig
> wrote:
>> On 30.04.2012 17:12, Jerome Glisse wrote:
>>> On Mon, Apr 30, 2012 at 11:12 AM, Jerome Glisse
>>> wrote:
On Mon, Apr 30, 2012 at 10:50 AM, Christian K?nig
wrote:
> Hi Dave
2012/4/30 Rafa? Mi?ecki :
> This is one more patchset bringing minor improvements to the current
> HDMI implementation. I think after this step I'll start working on
> moving Evergreen HDMI code to the separated file. Some cleanups and
> making ACR re-usable were needed before that.
>
> Patches dep
> OK, this time bisecting started off relatively smoothly (doing the same
> "backwards" bisect on the branch-o-reverts as last time), but then my
> disk died halfway through... So I'll post the partial bisection results
> now (11 commits left to test), but I clearly have other things to fix
> befo
On Tue, May 1, 2012 at 8:22 AM, Christian K?nig
wrote:
> On 30.04.2012 17:45, Jerome Glisse wrote:
>>
>> On Mon, Apr 30, 2012 at 10:50 AM, Christian K?nig
>> ?wrote:
>>>
>>> With that in place clients are automatically blocking
>>> until their memory request can be handled.
>>>
>>> v2: block onl
On 2012-05-01 16:09 +0100, Alan Cox wrote:
> > OK, this time bisecting started off relatively smoothly (doing the same
> > "backwards" bisect on the branch-o-reverts as last time), but then my
> > disk died halfway through... So I'll post the partial bisection results
> > now (11 commits left to t
On Tue, 1 May 2012 11:31:23 -0400
Nick Bowler wrote:
> On 2012-05-01 16:09 +0100, Alan Cox wrote:
> > > OK, this time bisecting started off relatively smoothly (doing the same
> > > "backwards" bisect on the branch-o-reverts as last time), but then my
> > > disk died halfway through... So I'll p
From: Rob Clark
Previously these functions would assume that vma->vm_file was the
drm_file. Although if in some cases if the drm driver needs to use
something else for the backing file (such as the tmpfs filp) then this
assumption is no longer true. But vma->vm_private_data is still the
GEM obj
From: Dave Airlie
These can all be trigged from userspace if you pass the right values.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5e81
On Tue, May 1, 2012 at 12:39 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> These can all be trigged from userspace if you pass the right values.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Alex Deucher
> ---
> ?drivers/gpu/drm/drm_crtc.c | ? 10 +-
> ?1 files changed, 5 insertions(+),
So it's pretty much the same patchset except for patch 7 (use mutex
instead of spinlock) and 9 & 10 which correspond to previous patch 9
split in two and the sa allocation being simplified.
The patchset can be found at :
http://people.freedesktop.org/~glisse/reset/
Cheers,
Jerome Glisse
From: Christian K?nig
Different rings have different criteria to test
if they are stuck.
v2: rebased on current drm-next
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_asi
From: Christian K?nig
It makes no sense at all to have more than one flag.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r100.c |1 -
drivers/gpu/drm/radeon/r300.c |1 -
drivers/gpu/drm/radeon/radeon.h
From: Christian K?nig
Just register the debugfs files on init instead of
checking the chipset type multiple times.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_ring.c | 31 +++
1 files chan
From: Christian K?nig
Removing all the different error messages and
having just one standard behaviour over all
chipset generations.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |7 ++-
drivers/gpu/drm/ra
From: Christian K?nig
Previusly multiple rings could trigger multiple GPU
resets at the same time.
Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |3 +-
drivers/gpu/drm/radeon/radeon_fence.c | 150 +
2 f
From: Christian K?nig
Aligning offset can make it bigger than tmp->offset
leading to an overrun bug in the following subtraction.
v2: Against initial suspicions this can't happen in mainline,
so no need to push it into stable.
Signed-off-by: Christian K?nig
Reviewed-by: Michel D?nzer
Revi
From: Christian K?nig
Make the suballocator self containing to locking.
v2: split the bugfix into a seperate patch.
v3: Jerome Glisse use mutex, no reason to use spinlock that
are more heavyweight than mutex
Signed-off-by: Christian K?nig
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/
From: Christian K?nig
Dumping the current allocations.
v2: convert to mutex
Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_object.h |5 +
drivers/gpu/drm/radeon/radeon_ring.c | 22 ++
drivers/gpu/drm/radeon/radeon_s
From: Jerome Glisse
The sa allocator is suppose to be a ring allocator, ie allocation
happen first at the end and if there is no more room we start at
the begining again. This patch make the code match this design.
sa_manager keep track of the start & end hole, it first try to
allocate in the end
From: Jerome Glisse
wakequeue is use in case we want to wait until we got something
that allow to allocate the object.
Signed-off-by: Christian K?nig
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_gart.c |2 +-
drivers/gpu
From: Christian K?nig
Instead of hacking the calculation multiple times.
Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_gart.c |6 ++
drivers/gpu/drm/radeon/radeon_object.h | 11 +++
drivers/gpu/drm/radeon/radeon_ring.c |6
From: Christian K?nig
Directly use the suballocator to get small chunks
of memory. It's equally fast and doesn't crash when
we encounter a GPU reset.
Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c|1 -
drivers/gpu/drm/radeon/ni.c
From: Christian K?nig
We should signal the caller that we haven't waited at all.
v2: only change fence_wait_next not fence_wait_last.
Signed-off-by: Christian K?nig
Reviewed-by: Michel D?nzer
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 files changed, 1
From: Christian K?nig
As discussed with Michel that name better
describes the behavior of this function.
Signed-off-by: Christian K?nig
Reviewed-by: Michel D?nzer
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h|2 +-
drivers/gpu/drm/radeon/radeon_device.c |2 +-
1 - 100 of 121 matches
Mail list logo